test(check): build the cross-engine collision after migration 9 runs

`check --rule <id>` selects every engine holding the id, and #385's test
proved it by seeding `vale/no-eval` beside the fixture's `sg/no-eval`.
Migration 9 now renames exactly that state, and `runCli` migrates on every
invocation through `migrateFixture`, so the collision was renamed to
`no-eval-sg`/`no-eval-vale` before `check` ever saw it: `--rule no-eval`
exited `RULE_NOT_FOUND` and the test died reading `.map` of an undefined
`results`.

The migration invalidated the setup, not the behaviour. An id held by two
engines still selects both, and a project can still reach that state — by
hand, or by a merge landing a same-id rule under another engine — which is
the case the new per-rule check in `verify` exists to catch. So the fixture
is migrated first and the second engine's copy seeded after, with a comment
naming migration 9 so the setup is not "simplified" back.

Also names the consequence in the changeset: an id passed to `--rule`
yesterday may not exist today, and that failure is `RULE_NOT_FOUND` rather
than a quiet zero findings.

Author: theCodeDrift

.changeset/rule-id-uniqueness.md

@@ -10,6 +10,6 @@ Two rules can no longer share an id across engines. `verify` fails a rule whose
 
 **A `runtime` rule is never renamed** and keeps the bare id, so a collision between `runtime` and another engine moves only the other one. Runtime rules are the signed and blessed tier, and this keeps the upgrade clear of that machinery. Nothing is left colliding either way, because one engine can only hold one directory per id.
 
-Everything the rename touches is inside the rule's own directory: the directory name, the rule file, its `id:` field, an sg rule's `.tests/` fixtures and their `id:` fields, and a Vale rule's `.vale.ini` breadcrumb and both segments of its `<id>.<id>` assignment. Every rename is printed — old path, new path, and each file rewritten — as is any runtime rule that kept its id, so you can see exactly what moved before committing it. Update any CI config, baseline file or suppression comment that names an old id.
+Everything the rename touches is inside the rule's own directory: the directory name, the rule file, its `id:` field, an sg rule's `.tests/` fixtures and their `id:` fields, and a Vale rule's `.vale.ini` breadcrumb and both segments of its `<id>.<id>` assignment. Every rename is printed — old path, new path, and each file rewritten — as is any runtime rule that kept its id, so you can see exactly what moved before committing it. Update any CI config, baseline file or suppression comment that names an old id — including `check --rule <id>`, which errors with `RULE_NOT_FOUND` rather than reporting zero findings when the id it names has been renamed out from under it.
 
 `.taskless/rule-metadata/<id>.yml` is left where it is rather than following either rule, since a symmetric rename gives it no owner. In practice there is nothing there: this CLI has never written a sidecar, because the service does not return the metadata block they are written from.

packages/cli/test/check-rule-filter.test.ts

@@ -319,6 +319,25 @@ describe("check --rule", () => {
       // `rules delete` refuses an ambiguous id because deleting the wrong rule
       // is irreversible. Measuring is not, and an unfiltered `check` would have
       // run both, so both run and `source` tells them apart.
+
+      // MIGRATE FIRST, THEN BUILD THE COLLISION. Migration 9
+      // (`0009-unique-rule-ids`) renames every id held by more than one engine,
+      // so a collision seeded into the fixture before it runs is renamed to
+      // `no-eval-sg`/`no-eval-vale` and `--rule no-eval` then names no rule at
+      // all — `check` exits `RULE_NOT_FOUND` and this test dies in `triples()`
+      // reading `.map` of an undefined `results`. `runCli` migrates on every
+      // invocation via `migrateFixture`, so the migration has to happen here,
+      // before the second engine's copy exists.
+      //
+      // That is not a trick to keep the old wording alive: it is the only way a
+      // project can hold this state now. The migration clears the collisions
+      // already on disk, and what remains is one created AFTER it ran — by
+      // hand, or by a merge landing a same-id rule under another engine — which
+      // is exactly the case the per-rule check in `verify` exists to catch.
+      // `check` still has to measure both, and `rules/rule-filter.ts` says so.
+      // Do not "simplify" this back into the `beforeEach`.
+      await migrateFixture(["-d", project]);
+
       const valeRule = join(project, ".taskless/rules/vale/no-eval");
       await mkdir(valeRule, { recursive: true });
       await writeFile(