fix: enable --agent respects settings.local.json overrides

[adrianmg]

Summary

• entire enable --agent <name> always wrote to settings.json, ignoring a stale enabled: false in settings.local.json left by a prior entire disable
• This caused entire status to show "Disabled" immediately after a successful enable

Root Cause

runDisable() writes enabled: false to settings.local.json. But setupAgentHooksNonInteractive() (the --agent code path) only wrote enabled: true to settings.json. Since settings.Load() merges local over project, the stale false in settings.local.json always won.

The interactive enable and --strategy paths already handled this correctly via determineSettingsTarget() — the --agent path was the only one missing it.

Fix

After writing enabled: true to settings.json, check if settings.local.json exists with a stale enabled: false and clear it. No signature changes, no new params — just 4 lines of targeted cleanup.

Repro (before fix)

entire enable --agent gemini     # writes enabled:true → settings.json
entire disable                   # writes enabled:false → settings.local.json
entire enable --agent gemini     # writes enabled:true → settings.json (local untouched)
entire status                    # → "Disabled (manual-commit)"

Affects

All agents using the `--agent` flag — not specific to any one agent.

[Copilot]

Pull request overview

This PR fixes a bug where entire enable --agent <name> failed to respect stale enabled: false settings in .entire/settings.local.json, causing entire status to incorrectly show "Disabled" immediately after a successful enable operation.

Changes:

• Added cleanup logic in setupAgentHooksNonInteractive to detect and clear stale enabled: false in settings.local.json after writing enabled: true to settings.json

[Copilot]

This bug fix lacks test coverage. Consider adding a test that reproduces the original bug scenario: enable with --agent, disable, then enable again with --agent, and verify that the status shows "Enabled". The existing TestEnableDisable integration test uses --strategy which already handled this correctly via determineSettingsTarget, so it wouldn't catch this specific bug in the --agent code path.

[khaong]

Thanks for the contribution! We ask that all PRs have a corresponding GitHub issue so we can discuss the approach first. Could you open an issue describing the problem this solves? Once we've aligned there, we'll prioritize the review. This helps make sure your effort doesn't go to waste.