Catalog work off the commit path; dense revisions; registration cost independent of catalog size (V6) #313

Part of epic #305.

Problem. Every publish rebuilds and topologically sorts all rules, re-formats the rule prefix and compares it to reuse the plan cache, and clones the relation map (src/storage_engine/mod.rs:2380-2381; src/rule_catalog.rs:868-921; src/storage_engine/snapshot.rs:231-240). Registering 200 rules took 9.6 s (48 ms per rule at a 200-rule catalog vs 21 ms at 50); 200 unrelated rules add 2 ms to every write->delta at 10k edges (report 4.2). Transient staging snapshots consume global revisions, so published revisions have gaps (src/storage_engine/write_program.rs:264-270; snapshot.rs:226).

Target. Compute the ordered rule list and prefix once per catalog change (cached in PersistentRules), not per publish; registration validates incrementally (stratification over the affected SCC only); staging snapshots use a separate counter so published revisions are dense and Unissued is exact.

Acceptance. Perf gate: write->delta and ack independent of unrelated rule count (B12); registering 200 rules <= 2 s and linear (B13); a revision sequence test shows no gaps across writes, guarded writes and proofs.

Size S. Dependencies V0. Order slot 3.