## Why

After Phase 1 establishes reliable Timetabler-to-Resource-Booking mirrors, shared Staff and Locations still cannot be safely booked from both systems without a real-time reverse command path and one authoritative all-or-none reservation decision. Eventual conflict discovery is unacceptable because either system could otherwise confirm an overlapping allocation before reconciliation.

## Cross-Repository Counterpart

This change is the Timetabler counterpart of `resource-booking-be` OpenSpec change `integrate-resource-booking-to-timetabler-phase-2`, pinned at commit `88c3cd5eaff085c70ab84f4e446b68268c87008b` for cross-service planning. That artifact contains 26 requirements, 72 scenarios, and 109 tasks across the RB-owned authority, command adapter, recovery, and rollout responsibilities. `traceability.md` maps the two task sets and is normative for ownership alignment; neither planning artifact opens the Phase 1 hard gate.

## What Changes

- Consume an authenticated, canonical, idempotent Resource Booking-to-Timetabler create/update/cancel command for one booking occurrence from a dedicated Kafka message role/topic, backed by a source mapping/receipt table with monotonic versions and manual durable-outcome-only offset handling.
- Reuse Timetabler's native booking model (`TtActivityType.booking=True` and `TtActivity.is_booking=1`) through one atomic booking application service that makes Staff, Location, time/week state, receipt, and TT outbound acknowledgement visible together.
- Keep protocol orchestration, occurrence expansion, RB identity mapping, retries, compensation, and reconciliation in the Resource Booking-owned adapter.
- Require an RB-owned authoritative reservation for Staff + Location + every occurrence/time range as one all-or-none operation through a bounded synchronous authenticated authority/status API before either system commits a shared-resource allocation.
- Enforce reserve/confirm/release/expire, idempotency, fencing, TTL/renewal, fail-closed availability, and conflict evidence on every Timetabler writer identified in Phase 1, including final engine results and bulk batches.
- Preserve the TT outbound event for RB-originated mutations with origin/causation metadata so it acts as an acknowledgement/echo and cannot create a synchronization loop.
- Add crash-safe compensation/reconciliation, pre-schedule occupancy hints, cutover seeding, observability, load/race tests, and a rollback that never returns to uncoordinated shared writes.
- Add an explicit hard gate: no Phase 2 production-code implementation may start until the approved Phase 1 completion report proves all required Timetabler and Resource Booking/adapter testing has passed.

## Capabilities

### New Capabilities

- `rb-booking-command-ingress`: Authenticated, versioned, idempotent, atomic create/update/cancel of native Timetabler booking occurrences from Resource Booking.
- `shared-resource-reservation-gate`: RB-owned authoritative, fenced, all-or-none conflict prevention applied to every TT and RB shared-resource allocation writer.
- `bidirectional-sync-recovery-rollout`: Echo suppression, durable acknowledgement, ambiguous-outcome recovery, reconciliation, observability, cutover, rollback, and the Phase 1 evidence gate.

### Modified Capabilities

None. Phase 1 capabilities remain separately reviewable and are a hard implementation dependency rather than being redefined by this change.

## Impact

- **Hard dependency:** Approved completion of `phase-1-outbound-resource-booking-sync`, including both services' full integration/regression/performance evidence. Resource Booking Phase 2 planning commit `88c3cd5eaff085c70ab84f4e446b68268c87008b` does not satisfy or waive this dependency.
- **Timetabler models/migrations:** A Resource Booking source mapping/receipt model under `api/models/` and `api/migrations/`, plus Phase 1 outbox/receipt dependencies.
- **Native booking domain:** Existing `api/models/tt_activity.py`, `api/models/tt_activity_type.py`, and current booking endpoints are refactored behind one atomic application service; the current `booking/create` followed by resource-type-specific `booking/schedule` calls is not used for integration orchestration.
- **Internal command/status interfaces:** A dedicated Kafka consumer and integration service apply typed occurrence commands with `read_committed`/manual-offset semantics, while a bounded authenticated Timetabler receipt/status interface resolves ambiguity. Exact topics, schemas, payload limits, ACLs and authentication mechanism remain decision tasks.
- **All Timetabler allocation writers:** Phase 1's shared scheduling service and adapters for engine schedules/swaps, manual constraint break, booking, unschedule/delete, current/requirement resource replacement, variants/JTA, imports, legacy/simulation consumers, cascade/pattern deletes, and management commands gain mandatory reservation evidence enforcement or are formally decommissioned/blocked.
- **Engine/pre-schedule:** Final engine assignments use atomic batch reservation before Timetabler locks/commit; pre-schedule incorporates RB occupancy/reservations as advisory input only.
- **Resource Booking-owned systems:** Sync adapter and shared reservation/availability authority implement orchestration, transformation, occurrence expansion, identity mapping, reserve/confirm/release/expire, fencing, retries, reconciliation, and RB-side enforcement.
- **Operations/config:** Internal auth, authority endpoints/transport, timeout/TTL/renewal, fail-closed flags, tenant/term/timezone mapping, ledgers, metrics, alerts, runbooks, and coordinated cutover controls.