Rule generations: build beside, swap at a revision; refuse drops that views depend on (V7) #314

Part of epic #305.

Problem. A rule change throws away every plan of the KG (snapshot.rs:231-236), retires every affected view key so new subscribers create a second view of the same query while old ones keep the retired view (src/protocol/subscription/views.rs:354-370), and resets every family. .rel drop silently empties dependent positive rules (only negation is guarded, src/storage_engine/mod.rs:1079-1109,2570-2607); a schema can be registered on a rule name unchecked (catalog_change.rs:139-168).

Target. On +rule/replace/.rule clear: build the next generation of affected dataflows beside the current one from the current arrangements, swap at a revision boundary, deliver old-vs-new diffs to subscribers of changed views, subscription_reset for views that disappeared; during the build the old generation serves reads and the write ack carries views_at (V14). Refuse dropping a rule or base relation that a deployed view depends on (conflict, names the dependents). Refuse schemas on rule names.

Acceptance. Tests: concurrent writes during a rebuild see no mixed-generation rows; arity change; late old-generation completion; measured rebuild pause and RSS for the lab pack at 1M edges; drop refusals; subscribers of a replaced rule receive exactly the diff.

Size M. Dependencies V5. Order slot 3. Supersedes #185.