fix(integrations): don't write an inert agent-context config when the extension is absent

[PascalThuet]

Fixes #2881.

Per your review, I dropped the back-fill approach (no more auto-install on install/switch/upgrade) and cut this down to the underlying bug.

integration install/switch/upgrade go through _update_init_options_for_integration, which wrote agent-context-config.yml whenever the config file already existed and created it from defaults otherwise. A project without the extension ended up with an inert config nothing reads. It now writes that config only when the extension is actually registered (registry.is_installed("agent-context")). Nothing gets installed or back-filled, and init is unchanged.

Tests (pytest tests/extensions tests/integrations tests/test_agent_config_consistency.py): 2381 passed, 15 skipped. Added unit + end-to-end coverage for both cases (extension absent, extension present).

Left out, can split into follow-ups:

• is_installed doesn't check the enabled flag, so a disabled-but-installed extension still gets its config updated.
• init still writes the config if the extension install itself fails (pre-existing).

[mnriem]

We are phasing using agent context files completely and the extension will only be available as an opt-in for single agent install. We are NOT going to support it for multi install and it will be entirely an opt-in at 0.0.12. So please limit to scope to that

[PascalThuet]

Thanks. Dropped the back-fill, so there's no auto-install on any path now. This just stops install/switch/upgrade from leaving an inert agent-context-config.yml when the extension isn't installed: the write now keys off registry.is_installed("agent-context") instead of the config file existing. init is unchanged. Can narrow it further if you'd prefer.

[mnriem]

Thanks for the investigation. The scenario this addresses — agent-context config written when the extension is absent — only occurs when a user upgrades the CLI but skips the documented project update step (specify init --here --force --integration <agent>). Our upgrade guide already covers this two-step process, and the worst case is an inert YAML file that causes no harm.

Additionally, agent-context is moving to fully opt-in at 0.0.12, so adding defensive infrastructure around it is working against the direction we're heading.

[PascalThuet]

Makes sense. If the inert config is harmless and agent-context is going fully opt-in at 0.0.12, this isn't worth the added surface. Closing this out. Thanks for the context.