Stabilize bridge CI with supported Windows integration coverage

[hetaoBackend]

Unrelated PRs such as #45 randomly failed because repository-wide node --test discovered cli-agent-bridge integration suites that explicitly enable its unsupported POSIX polling tracker. Under CPU pressure, a short-lived parent and child can both exit before polling captures their identities. The tracker must quarantine that unverified tree, even when the backend exits successfully (CI failure).

Move the two server suites to an explicit integration/ directory and update the existing Windows workflow to execute both complete suites against the supported Windows Job Object containment. Root package changes also trigger the Windows job. Default repository checks retain the process-tracker fixtures and workspace-lock tests; explicit POSIX integration remains available for diagnostics. Document these validation boundaries and commands.

This changes test discovery and workflow wiring only. Production code, containment policy, and integration assertions are unchanged. Existing platform-specific skips remain unchanged.

Validation:

• Reproduced the fail-closed exitCode: 0 / treeTerminated: false result with real short-lived Git subprocesses, including a 1-CPU Linux pressure run.
• Final local npm run check: 345 tests, 344 passed, 1 existing skip, 0 failures; 28 hosted plugin manifests and all examples validate.
• Verified the renamed entry points with protocol initialization, Codex argument templates, and unsupported-platform boundary tests.
• GitHub Ubuntu CI passed three consecutive attempts on the identical head 189b1b04f5dc80cf0ac3606dda128c93f29e6963 (run). CodeQL and the complete Windows integration run also passed on that same head.

[modacker]

Independent confirmation from the affected-PR side: across four runs we recorded five distinct failing test names in this family (a fetch in another repository…, new-branch attribution considers baselines beyond the first 256 tips, a workspace fetch makes commit attribution explicitly unavailable, a new branch forked from a divergent branch…, a delegation cancelled while queued for the lock never starts its worker) with a constant treeTerminated:false error family, green main runs interleaved between red fork-PR runs, and the same head passing the full 493-test gate on an idle local Ubuntu box (482 pass / 0 fail) — all consistent with the identity-capture race under CPU pressure described here. Moving the suites to explicit integration/ with supported Windows Job Object coverage looks like the right containment; glad the evidence thread on #43 fed into this.