Tunn3l booking integration + consolidated connector tables

Shipped 2026-06-24

Onboarded Tunn3l as a third booking-system integration, mirroring the FuseMetrix flow: member validation at check-in, booking creation that rejects duplicate bookings, and currency-gated logbook entries. Tunn3l activity is also emitted as structured, vendor-tagged application logs alongside the database audit trail.

Internally, the per-vendor connector tables (fuse_metrix_*, convergence_*) were consolidated into a single set of connector_* tables discriminated by a vendor column. This is an internal data-model change with no partner-facing impact — external payloads and authentication are unchanged.

Because vendor is now a bound parameter rather than part of an interpolated table name, the ALLOWED_BASE_TABLE_NAMES whitelist that guarded the old dynamic-SQL path is retired by construction.

Fixes shipped alongside

• Validation errors returned 500 instead of 422. connector_history.error_msg was varchar(100), and the audit write was awaited before responding — so a Missing required fields: … message longer than 100 characters (6+ missing fields; Convergence requires 10) failed the INSERT and surfaced as an HTML 500, with the audit row silently lost. The column is widened to varchar(255) and the audit write can no longer determine the response.

• Tunn3l threw on banned or deleted members. getFullMemberDetails() returns null for a missing, banned or deleted member; FuseMetrix and Convergence guard for that, Tunn3l did not — and the throw landed after the booking row was committed, leaving an orphaned booking the partner could never retry.

• Jira: TUN-661 

• PR: #744 

• Author: @alexhobday