fix(core): watch for skills/ inside existing .agents and .claude roots - #55280

Fixes the flaky config plugin reloads > loads skills when <root> appears after startup test.

Failing runs:

• dev run 38482970830 (linux, .agents)
• PR run 38419395049 (windows, ../.claude)

error: Timed out waiting for config plugin reloads
(fail) config plugin reloads > loads skills when .agents appears after startup [1217.60ms]

Cause

• Product bug: ConfigCompatibilityPlugin only watched <root>/skills when it already existed. If .agents or .claude existed without skills/, a later skills/ was never loaded until restart.
• Same race in the test: Bun.write(".agents/skills/probe/SKILL.md") creates the directories one by one. When the refresh ran between mkdir .agents and mkdir .agents/skills, the skill was lost.
• Second gap: each refresh cleared every watch and reattached it, and the scan did not wait for the new watch. Writes made before the watch attached were lost.
• Test timing: each wait polled for about 1 second of wall-clock time, so slow CI runners also failed.

sequenceDiagram
  participant T as Test / user
  participant C as Config parent watch
  participant P as Compatibility plugin
  T->>C: mkdir .agents
  C->>P: change event, refresh
  P->>P: realPath(.agents/skills) fails, no watch (before)
  T->>T: mkdir .agents/skills, write SKILL.md
  Note over P: nothing is watching, skill is never loaded

Fix

• compatibility.ts
  • Watches <root>/skills as a file target when it is missing, so its creation triggers a refresh. This is the same approach as ConfigSkillPlugin.
  • Passes a readiness callback to watcher.subscribe, so a newly attached watch triggers one rescan. Config uses the same pattern.
  • Removes only the stale watches. Live watches stay attached, so readiness does not loop.
• reload.test.ts
  • Replaces the 1-second polling with settle(events, action, condition). It subscribes to config.updated or skill.updated before the action and checks the condition on each event. The test runner timeout is the only time limit.
  • Creates the root before skills/, which covers the product bug. Recreating the whole tree in one write still covers the concurrent case.

Not in this PR

• Exit code 139 in the dev run: turbo crashed, not Bun. The log shows error: Failed to run "turbo" due to signal SIGSEGV after bun test exited normally with code 1. In this window it happened in 2 of 19 failed linux unit jobs, and only after a task failed. That matches a known turbo 2.10.x crash when a run ends with a failed task. The repo pins turbo 2.10.2.

Added by the opencode bot (AI-generated).

Related: #54114, #53393, #42478