fix(google): address a booking's event by the calendar it was created on

[asm0dey]

The bug

A booking row stored only google_event_id — never which calendar the event was created on. Every later write (updateEvent, updateEventDetails, deleteEvent) resolved the calendar from GoogleCalendar.writeTarget(ownerId), i.e. whatever the owner's write target is now.

Rotate the write target — or connect a different Google account — between booking and cancel/reschedule, and calit addresses the event on the wrong calendar. Google answers 404. Since 1.20.1 deleteEvent treats 404 as "already gone", so the cancel succeeds locally while the event lives on forever on the old calendar, invisible to calit. Reschedule 404s loudly instead — noisy, but still unable to reach the event.

Closes the calit-rma2 bean, and unblocks calit-bh5t (per-meeting-type write target), which would otherwise orphan every existing booking the moment a type gets an override.

The fix

Store the address on the booking at creation time, and address every later write by that stored address instead of the owner's current write target.

• V26 adds two nullable columns to booking: google_calendar_id text and google_credential_id bigint REFERENCES google_credential(id) ON DELETE SET NULL.
• New record CalendarRef(Long credentialId, String googleCalendarId); Booking.calendarRef() returns one, or null.
• CalendarPort.updateEvent / updateEventDetails / deleteEvent each take a CalendarRef. GoogleCalendarPort.writeAddress(ownerId, ref) resolves it behind an owner-scope guard — a ref whose credential is missing or belongs to another owner falls back to the owner's current write target.
• CreatedEvent reports the address it actually wrote to; BookingService persists it behind a null guard.
• Reschedule captures priorRef before clearing, so the re-approval delete still reaches the old calendar. Both address columns are cleared wherever google_event_id is cleared, and nowhere else.
• groupEventId + organizerOwnerOf collapsed into one groupEventRow(UUID) lookup, so the event id, owner, and ref are guaranteed to come from the same row.

Deliberately no backfill. NULL means "address unknown, resolve as before". Stamping old rows with the current write target would be confidently wrong for exactly the bookings this bug affects.

The create side still resolves the owner's default write target — the per-meeting-type override is calit-bh5t's job, and it reuses the CalendarRef type introduced here.

Dependency bumps folded in

Supersedes #131 and #132 (both pom.xml-only, both green on their own CI):

• jackson-core 2.22.1 → 2.22.2
• spotless-maven-plugin 3.9.0 → 3.10.0 (re-checked: 371 files clean, no reformatting)

Close #131 and #132 when this merges.

Verification

• Full suite: 830/830 green, 0 failures, 0 errors, 0 skipped — re-run after the dependency bumps and again after the review fixes.
• spotless:check: clean, under the bumped plugin.
• quarkus:dev boot: Flyway migrated to v26 - booking calendar address, app started, zero errors — Hibernate's validate strategy accepted the entity against the migration. Caveat: Dev Services hands out a fresh database, so this proves V26 applies in sequence, not that it applies onto a pre-existing populated DB.
• Each task carried its own spec + quality review, plus a whole-branch review at the end. Every finding raised was a test gap, not a logic defect — no Critical issues, and no production line changed as a result of review.

Findings raised and fixed

Three rounds found the same class of hole: assertions that used any() in the CalendarRef position, so a write site could regress to the pre-fix behaviour without turning a single test red.

• 1e8c3ef — the reschedule delete had nothing pinning it. Added a test that fails if the priorRef capture moves after the clearing block.
• bec2dd1 — the updateEvent / updateEventDetails sites had nothing pinning them either, and StoredCalendarAddressTest seeded one credential for both the write target and the ref, so it never actually tested the credential half of the address — the multi-account case, which is the second half of this bug. Three tests added, each proven to fail against the specific regression it guards.

Still matched with any(), tracked on calit-vi8n with the exact tests to write: the group-details site and declineGuest. Both are correct as written — this is regression insurance, not a live risk.

Cleared with no action

The whole-branch review re-derived rather than assumed: the owner-scope guard in writeAddress (a booking's stored credential id cannot reach another owner's calendar — it is guarded and never user-supplied), the NULL-address paths for pre-migration rows, and migration safety. On the last: ADD COLUMN of two nullable columns is metadata-only, and rollback to a pre-V26 app is safe — no ignore-migration-patterns is set, so Flyway's default *:future applies, and Hibernate validate only checks mapped columns.

Notes for review

• Commit 02c6605 still carries a wip(booking): subject — squash-merge, or reword before merging.
• No new user-facing strings, so no de/he translation work.
• The behaviour change is user-observable, so it owes a docs-site changelog entry in whichever release ships it.
• Deferred deliberately, not dropped: calit-8dqz (what a 404 should mean now the calendar is known — this branch only logs the distinction and keeps 1.20.1's blanket tolerance), calit-64hy (disconnecting an account leaves a half-address that 500s on reschedule), calit-wsdr (index the new FK column).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
92.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud