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.

Start by reading RFC 0012 section 8 and RFC 0014, because the issue requires an RFC before implementation. The design must define opt-in restart re-admission semantics while preserving policy-off behavior, then map that to an additive public API and deterministic tests. Done means the RFC covers all listed lifecycle cases and the implementation is proven through TestDriver and production reconciliation/lifecycle coverage.

Escrita pelo modelo de indexação a partir do texto da issue.