Guard every static import cycle in server/services with a shrinking baseline

[atomantic]

Summary

• server/services/serviceImportCycles.test.js guards the whole server/services directory against new static ESM import cycles. The two existing guards (agentImportCycles.test.js, twinImportCycles.test.js) each fail only on a ring touching their own cluster, so ~1000 modules had nothing stopping the next one. A static cycle is a boot-order hazard: whichever member evaluates first sees undefined for the others' bindings, and no behavior test notices until an unrelated import-order change surfaces it.
• The baseline is a ratchet, asserted both ways: a cyclic component that is not in KNOWN_CYCLIC_COMPONENTS fails, and a listed component that is no longer detected fails too — so the list can only shrink, and a fixed cycle cannot leave a stale entry behind.
• Five components are live today, each recorded against the issue that removes it: Break the taskLearning metrics <-> routing static import cycle #5916, Break the loraDatasetCaption <-> loraDatasetGenerate static import cycle #5917, Break the pipeline manuscriptReview <-> manuscriptFix static import cycle #5918, Break the sharing peerSync <-> peerSyncReceive static import cycle #5919, Shrink the 22-module seriesAutopilot / creativeDirector import cycle #5920 (filed with this PR).
• findImportCycleComponents joins the shared parser in server/lib/staticImportGraph.js rather than getting a module of its own — that file already exists for exactly this reason, and two copies of a structural matcher is how a guard rots. README row and barrel entry updated.
• The existing cluster guards keep all of their own assertions (facade re-export rules, deferred-import bans); those check properties a general acyclicity walk does not.

Why components rather than rendered rings

findImportCycles is depth-first, so which rings it names depends on where the walk enters a component — and it enters wherever readdirSync put the first file, i.e. filesystem order, not alphabetical. That is fine for an "is this empty?" assertion and unusable as a baseline: the same untouched graph would produce a different list on another machine, so CI would go red over a change nobody made. Strongly-connected components are a property of the edges alone. They are also the truer picture — the DFS walk names 8 modules in the autopilot ring; the component is 22.

Test plan

• cd server && npm test — the new suite passes (5 tests); agentImportCycles, twinImportCycles, lib/index.test.js and lib/generatedManifests.test.js stay green.
• Acceptance probe 1 (a new cycle must fail). Temporarily added import './cosForgeSpawnGate.js' to agentState.js, closing a two-module ring. The guard failed and named both the component and the ring that closed it. Reverted.
• Acceptance probe 2 (a stale baseline entry must fail). Temporarily removed the taskLearning/routing.js → metrics.js back-edge without touching the baseline. The other direction failed, naming #5916 and the entry to delete. Reverted.
• The suite carries its own negative controls: a hand-built 3-node cyclic graph must be reported, an acyclic graph must report nothing, a self-importing module must be reported, and the services graph is size-checked so a resolver gap cannot read as a clean sweep.
• Nine unrelated suites (imageGen routes, sprites atlas, videoGen, trellis normal bake, public/peer-sync auth integration, setup-data-drift) fail identically on main without this branch — pre-existing local-environment failures, not introduced here.

Closes #5693