Add opt-in subscription restart rate control

## Summary

Add opt-in rate control for subscription re-admission so a source that finishes or fails repeatedly cannot create a tight restart loop.

Today, a subscription that remains declared is restarted at the next reconciliation point after it finishes. That default is intentional and must remain unchanged when no policy is configured. However, a source such as a failing WebSocket can form a `restart -> emit -> update -> reconcile -> restart` loop and reconnect without a bound.

## Design boundary

This changes runtime scheduling semantics, so an RFC must precede implementation. RFC 0012 section 8 owns the restart-rate extension point; the design must also reconcile its policy with RFC 0014's kernel scheduling invariants.

Keep two responsibilities distinct:

- runtime-level admission control, such as a minimum restart interval or safety fuse;
- source-specific failure policy, such as exponential backoff for WebSocket or HTTP sources.

The initial runtime API should be opt-in. First admission, including bootstrap, must remain immediate. Existing behavior must remain the policy-off behavior.

## Acceptance criteria

- [ ] An RFC defines policy-off compatibility and policy-on re-admission semantics.
- [ ] The RFC covers natural finish, startup failure, explicit replacement, cancellation, scope teardown, and shutdown.
- [ ] The RFC states how an elapsed delay makes the runtime dirty and wakes a parked kernel, or explicitly chooses a passive policy that promises no automatic retry.
- [ ] An additive public API configures restart rate control without changing existing declarations.
- [ ] Deterministic tests prove that a restart storm is bounded and that the policy-off path is unchanged.
- [ ] `TestDriver` coverage exercises the production reconciliation and lifecycle path.