10 — Make restreamer bookmarks and lifecycle handoff recoverable

## Objective Case bookmarks and meeting streaming effects triggered by engine commands survive enqueue/worker failures without duplicate bookmarks or untracked background chains. ## Code and evidence app/models/case.rb#add_tv2_bookmark rescues and returns true; app/models/meeting.rb streaming_start!/restreamer_start/streaming_end!; app/services/muni_tv/{pass_through_manager,restreamer}.rb; app/jobs/muni_tv/{create_restreamer_bookmark_job,stream_manager_job}.rb. Bookmark creation is an untracked child enqueue; Restreamer#post returns responses without checking success; StreamManagerJob sleeps/re-enqueues itself. Enqueue success is not effect completion or durable chain recovery. ## Changes - Give each engine bookmark a stable event/effect key and establish receiver idempotency/recovery lookup. Do not repeat a remotely created bookmark after local ack loss. Preserve event/lifecycle metadata and timing required by the remote bookmark contract. - Execute bounded delivery-aware operations or carry the delivery ID to child jobs that acknowledge actual completion; persist remote IDs/outcomes if supplied. - Surface non-success HTTP responses, configuration errors and timeouts; remove swallowed-success behavior in the durable path while reusing existing adapters. - Move engine-owned streaming effects from controller continuation to the consumer plan. Preserve existing streaming flags, mode and privacy behavior. - For the long-lived stream manager, either execute a bounded desired-state operation or hand off to persisted desired state with independent reconciliation. Starting a self-rescheduling job once is not a durable handoff. Retry must not create parallel unmanaged chains. - Generation/lifecycle guards prevent delayed starts after end/reset and allow cleanup. Split bookmark and lifecycle effects so bookmark failure does not prevent voter UI or safety cleanup. ## Acceptance and tests Proposed outbox restreamer consumer/job specs; reuse existing MuniTV tests where present. Cover enqueue loss, child crash, remote HTTP failure, ambiguous bookmark success, duplicate delivery, lost stream-manager continuation, disabled/not-streaming meetings, end-before-start delivery and stale generations. Validate stable-key behavior with the paired service and real staging bookmark counts. Run bundle exec rspec spec/services/voting_engine/outbox (after adding these specs) and affected existing MuniTV suites; RuboCop changed Ruby. ## Depends on https://task.matda.me/tasks/tsk_2qravp6n9b — contracts. https://task.matda.me/tasks/tsk_beu5nmfqfj — worker/ledger. https://task.matda.me/tasks/tsk_5fdrm4pptn — owned callbacks. Coordinate meeting entrypoint removal with task 06 and router/Teams adapters. ## Questions - Does the deployed restreamer support idempotent bookmark creation and lookup by a caller-supplied stable key? If not, which paired repository/release will implement it? - Can delayed bookmark creation preserve the original event timestamp/position, or does its API require a timestamp extension? Verify before claiming replay preserves existing bookmark behavior. - If upstream support is unavailable, is a documented ambiguous-delivery reconciliation exception approved? Do not silently risk duplicate bookmarks.