feat(booking-engine): add request-first booking workflow

[agustinjch]

Summary

• add a separate booking_requests aggregate and the property-level bookingMode: instant | request switch
• add the three-step guest flow for dates, configurable application questions, and required | optional | disabled saved-card collection
• add the staff review queue with independent accept/deny and payment actions, including partial saved-card charges, external payments, refunds, retentions, extras, and stay amendments
• add transactional email, audit/outbox persistence, immutable quote and accepted-price snapshots, tenant scoping, permissions, and end-to-end coverage

Safety and compatibility

• request submission does not create a reservation, deduct inventory, or charge the guest
• acceptance revalidates availability and price, is idempotent, and can create the reservation with zero paid
• all payments are explicitly staff-initiated; there are no automatic captures
• zero availability remains a waitlist concern
• existing properties keep bookingMode=instant, and the instant booking/deposit path remains unchanged
• Stripe card data is handled through SetupIntents; HAIP stores tokenized references only

Verification

• pnpm test — 2,172 passing tests across 258 files (14 skipped)
• pnpm build
• incremental booking-request migration replayed against PostgreSQL with a non-superuser role
• real Stripe test-mode SetupIntent and request submission verified in the browser with a Stripe test Visa
• final focused review: no Critical or Important findings

Closes #332

[agustinjch]

Thanks for the feedback. I have pushed a full remediation pass focused on protecting the default hotel flow while keeping booking requests fully opt-in.

What changed:

• Fixed Stripe refund reconciliation for instant bookings, including cumulative refunds, negative ledger movements, and folio balance recalculation.
• Hardened Stripe webhook ownership and correlation. Unrelated Stripe events remain harmless no-ops; malformed or contradictory HAIP-owned events now fail so Stripe can retry them.
• Added regression coverage proving that instant booking remains the default and request-mode persistence is activated only when a property explicitly enables it.
• Made payment installments, allocations, refunds, returns, retentions, and webhook consequences idempotent and safe under concurrent execution.
• Fixed durable webhook failures so unsuccessful delivery remains pending and retryable.
• Preserved the configured card-collection policy and separated booking-application identity from individual Stripe card-setup attempts.
• Rejected duplicate ancillary services across request and instant-booking APIs.
• Fixed dashboard issues involving duplicate financial submissions, realtime cache invalidation, and local processed-at timestamps.
• Added transactional auditing for booking configuration and stricter currency/minor-unit validation.
• Replaced the runtime raw SQL introduced by this PR with Drizzle-based queries and schema operations.
• Hardened the migration and backfill path for concurrent writers and rolling deployments.

Validation completed on head 084380a:

• 2,235 tests passing across 259 files in the same environment used by CI.
• Full build and workspace typecheck pass.
• Lint completes with zero errors.
• PostgreSQL-backed default-flow and request-mode release gates pass.
• The final diff contains no newly introduced runtime raw SQL.
• A complete independent review found no remaining Critical, Important, or Minor issues.

The branch is ready for another review.

[telivity-otaip]

Focused follow-ups from this work are split into separate PRs for review:

• feat(email): add bounded timeouts for outbound email providers #349 — bounded outbound email transport timeouts
• feat(webhook): dedupe deliveries with logicalEventId #350 — webhook delivery dedup via logicalEventId
• feat(api): add shared confirmation number and property date helpers #351 — shared confirmation number and property date helpers
• chore: sync README test counts from passing vitest results #352 — README test count sync script
• feat(payments): ignore unrelated Stripe account webhook events #353 — ignore unrelated Stripe account webhook events
• feat(booking-requests): add optional booking-requests module #348 — optional @telivityhaip/booking-requests package (depends on the above)

Co-authored-by: Agus agustin.jch@gmail.com

[telivity-otaip]

Focused follow-ups from this work are split into separate PRs for review:

• feat(email): add bounded timeouts for outbound email providers #349 — bounded outbound email transport timeouts
• feat(webhook): dedupe deliveries with logicalEventId #350 — webhook delivery dedup via logicalEventId
• feat(api): add shared confirmation number and property date helpers #351 — shared confirmation number and property date helpers
• chore: sync README test counts from passing vitest results #352 — README test count sync script
• feat(payments): ignore unrelated Stripe account webhook events #353 — ignore unrelated Stripe account webhook events
• feat(booking-requests): add optional booking-requests module #348 — optional @telivityhaip/booking-requests package (depends on the above)

Contributor: @agustinjch

[agustinjch]

Thanks again for the original vertical slice — it made the full workflow and infrastructure impact visible, and it remains the source of the focused PRs listed above.

My understanding is that #347 should not be merged after #349–#353 and #348. Doing so would restore the booking-request implementation and migrations directly into core, duplicate the package work, and reintroduce the migration-prefix conflict with #350. Once the focused PRs are complete, this PR should be closed as superseded.

Before closing it, I would make sure the following generic hardening present here is not lost in the split:

• generic payment endpoint permissions/safe response protections and their regression tests;
• accepted-pricing protections in the Folios UI;
• WebSocket property-room rejoin/recovery after reconnect;
• the fuller accessible Modal hardening;
• booking-request migration safety, schema, and remediation tests.

The late financial/Stripe fixes appear materially represented in #348, and the normal instant-booking refund repair is preserved. The items above can be moved into #348 where directly required or into small independent core-hardening PRs.

One administrative detail: #347 currently contains Closes #332. Because this PR will be closed without merging, please move Closes #332 to #348 (or close the RFC manually once the package lands).

With that handoff complete, I am happy for #347 to serve as the historical/source PR and be closed as superseded, with the contribution credit preserved across the split PRs.

[telivity-otaip]

Closing as superseded by #348, which merged to main at e71537b.

The request-first booking workflow ships as the optional @telivityhaip/booking-requests package (flag-gated, real package boundary, Agustin’s packaging review addressed). This PR’s monolithic integration path is no longer the merge target.

Thank you @agustinjch — contributor credit remains in packages/booking-requests/README.md. No further action needed on this PR.