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.