MaintainedView standing queries: subscriptions are diffs of the view between revisions (V10) #317

Part of epic #305.

Problem. Every affecting commit re-runs the whole query on a fresh snapshot and diffs full HashSets of JSON rows, three copies of the result are kept, and the dependency filter is relation-name granular (src/protocol/subscription/reevaluate.rs:124-153; result_set.rs:55-136; subscriber.rs:57,79,155; dependencies.rs:22-53). Measured: 70 ms / 3.0 s per write with one subscriber at 1M edges; 1,000 keyed members 131 ms CPU per write (report 4.2).

Target. A StandingQuery implementation MaintainedView { kg, view, key: Option<Binding> }: snapshot = cursor read of the view at the frontier; refresh = consolidated updates of the view in (last_revision, frontier] (key-filtered for bound subscriptions), read from trace batches; the maintainer emits a per-commit changed-key index and the hub rings only subscribers of changed keys; the hub is driven by maintainer events (commit r applied) instead of relation-name notifications; subscription_error carries the revision; the recompute strategy stays behind the flag. Protocol, ViewRegistry, doorbells, chunking, access checks, generations and seq unchanged.

Acceptance. Oracle: maintained deltas vs recompute deltas vs naive over random histories, including reconnect/catch-up (subscriber skipped publications) and rule changes; B6-B9 pass (write->delta <= 5 ms p50 for both views at 1M edges; 1,000 keyed subscribers <= 2 ms CPU per write; ten keyed subscribers on the recursive view <= 5 ms CPU and < 1 GB); no rule_evaluations during refreshes; raw WS, SDK and gateway finding histories (tests/) pass in both modes.

Size L (split allowed: unbound / keyed). Dependencies V9. Order slot 4. Supersedes #186, the DD remainder of #133, #238.