docs(rfc): add queue-scoped speculation RFC

## Summary

### Why?

The current speculation design (doc/rfc/submitqueue/speculation.md) materializes a batch's full 2^N speculation tree up front, persists it, and re-walks all of it on every event — and each per-batch pass additionally triggers a queue-wide prioritize round. The enumerate/score/select seams force the materialized tree through every contract boundary, which caps how far the dependency limit can ever scale and couples per-event cost to tree size.

### What?

Adds an RFC proposing a queue-scoped execution model for speculation: a queue-keyed speculation pass (pure function of ground truth, one pass per dirty signal, self-arming tick backstop) replaces the batch-keyed speculate and prioritize stages; persistence inverts to bets-not-candidates (content-addressed bet records with a correctness-required attempt counter, an executor-owned execution record, and a per-queue ledger as bet index and membership linearization point); extension moves to a single Speculator seam with a composed Belief/Generator/Admitter default. The RFC records the adversarial validation of each load-bearing assumption (single-writer, crash choreography under no-transactions NoSQL, merge safety, cost ceiling), the design decisions with rejected alternatives, a shadow-mode migration path, and open questions.

Merge finalization is strict: the pass advances a batch to merge only when its predecessors have actually merged (observed via mergesignal). speculation.md's optimistic merge hand-off is deliberately dropped and deferred to its own design, recorded as an open question, to keep merge-executor concerns out of the speculation pass.

Author: behinddwalls