feat: store app-only Graph credentials in the staff-api tenant (PPT-2000)

[camreeves]

Stacked on #441 (which stacks on #440). Closes the gap where the 1-click flow registered the app-only "PlaceOS Bookings Visualiser" application — with admin-consented Calendars.ReadWrite / Group.Read.All / User.Read.All application permissions — but never minted a secret for it and discarded its client id, so the consented app-only Graph access was unusable and calendar credentials still had to be typed into Backoffice → Admin → Staff API by hand.

What changes

• create_app now mints a client secret for the visualiser app (same addPassword call the auth app already used, wrapped in the replication retry).
• New flow step "Connect room calendar access": writes {tenant, client_id, client_secret} into the staff-api Tenant for the domain — created if the domain has none, updated otherwise. The model encrypts credentials at rest (Level::NeverDisplay) and validates them as Office365Config.
• Existing delegated tenants are switched to app-only (delegated: false). Rationale: the flow already owns the domain's Microsoft configuration (login_url, outlook_config) and the visualiser app exists precisely to provide app-only access. Delegated mode remains one toggle away in Backoffice.
• Ordering fix: the tenant row is now guaranteed to exist before create_outlook_config, which previously silently no-oped on a fresh domain (Tenant.find_by? → log + return).
• Progress page picks the new step up automatically (step list is data-driven).
• Two ameba nits from feat(tenant_consent): live progress page for the admin-consent flow (PPT-2032) #441 fixed (rescue flow_error naming, verbose block).

Verification

• crystal build --no-codegen clean on 1.21; ameba clean on all touched files.
• 2 new specs (spec/tenant_consent_spec.cr): create-when-missing and switch-existing-delegated — both assert the stored ciphertext decrypts to exactly the written credential and that place_calendar_client builds from the row.
• Full browser e2e on dev to follow (same standard as fix(tenant_consent): retry Graph calls that race directory replication (PPT-2000) #440/feat(tenant_consent): live progress page for the admin-consent flow (PPT-2032) #441: button → MS consent → Accept → progress page → verify tenant row + staff-api calendar still answers).

The triggers service (GraphSecretExpiryFinder) will start probing the stored credential for secret-expiry metadata — that's existing behaviour for any non-delegated office365 tenant.

🤖 Generated with Claude Code

[camreeves]

Bug found by the first dev e2e run — fixed in a2acb90

The first full browser run (Integrate Azure → real MS consent → Accept) completed cleanly end to end, but it configured the wrong tenant, and that exposed a defect this PR would otherwise have shipped.

What happened: the flow looked up the staff-api tenant (and built the Outlook add-in URLs) from request.hostname. Backoffice can drive the integration for any authority, so integrating authority-AzureDemo2000 (domain azure-demo.placeos-dev.aca.im) while browsing Backoffice on placeos-dev.aca.im wrote the demo's Microsoft configuration onto the dev domain's own tenant row — flipping it from delegated to app-only and replacing its calendar credentials.

This half is pre-existing, not new: create_outlook_config has always keyed off the request host, which is why the dev tenant's outlook_config.app_id has been silently rewritten by every test run. This PR's credential write inherited the same lookup and widened the blast radius from one Outlook field to the calendar credentials themselves — which is what made it visible.

Fix: the authority record already supplied the domain used for the auth app's redirect URI; it is now used for the tenant lookup, the Outlook identifier URIs and the add-in URLs as well. Only the consent callback URL still derives from the request host, where it must (it has to match the redirect URI registered on the management app).

New spec pins the behaviour: a bystander tenant on a different domain must be byte-identical after a flow targeting another authority's domain.

Dev state: the affected row was restored from a pre-run backup (delegated flag and original credentials verified back in place). Its original outlook_config.app_id is unrecoverable — prior runs had already overwritten it before any backup existed; calendar access, the part that matters, is fully restored. All test app registrations have been deleted from the sandbox tenant (back to its 5 permanent apps).

Re-verification with the fixed image is running; will post the result.

[camreeves]

Re-verified end to end on a2acb90 — passing, with the negative case proven

Full browser run on dev (Integrate Azure → Microsoft's real consent page → Accept):

Positive: a new tenant row was created for the authority's own domain — azure-demo.placeos-dev.aca.im, platform: office365, delegated: false, credentials populated, Outlook config pointing at the auth app. Progress page showed all 5 steps with live replication narration, then redirected to the Authentication tab.

Negative (the point of the fix): every other tenant row is byte-identical to the pre-run baseline — md5 of credentials unchanged and updated_at untouched across all 8 pre-existing rows, including the dev domain's own row which the previous build clobbered.

App-only Graph access actually works

Using the provisioned "PlaceOS Bookings Visualiser" app: service principal present with 3 admin-consented Graph app-role grants; an app-only client-credentials token minted successfully; GET /users OK, GET /groups OK, and GET /users/{id}/calendar returned a real mailbox's calendar — calendar data with no signed-in user, which is the capability this PR exists to enable. (A temporary secret was minted for that test and removed; only the flow's own secret remains.)

Honest boundary: I could not independently decrypt the stored credential to compare it byte-for-byte with what Graph issued — my own reimplementation of PlaceOS::Encryption fails on known-good pre-existing rows too, so it proves nothing either way. What is proven server-side is that the model's before_save validation decrypts and parses Office365Config (tenant/client_id/client_secret all required) or the save raises — and the save succeeded.

Two findings for follow-up (not blocking this PR)

1. places/microsoft.graph.room returns 403. The flow grants Calendars.ReadWrite, Group.Read.All and User.Read.All, but not Place.Read.All. Room mailbox access works (the booking path), but anything using the Graph places API for room discovery will fail. Worth deciding whether create_app should request it.
2. GraphSecretExpiryFinder (triggers) can't monitor these tenants. It calls GET /applications(...), which needs Application.Read.All — not granted. Flow-provisioned tenants will log an error each cycle and never populate secret_expiry, so expiry monitoring is blind for exactly the tenants this feature creates. The secret it mints expires 2028-08-05.

Sandbox tenant is back to 5 permanent apps plus the one live demo pair; all other test registrations deleted.

[camreeves]

Place.Read.All added (2d64a87) and verified on dev

Role ID taken from Graph rather than memory — GET /servicePrincipals?$filter=appId eq '00000003-0000-0000-c000-000000000000' → appRoles, giving Place.Read.All = 913b9306-0ce1-42b8-9137-6a7df690a760. The same response confirmed the three IDs already in the code are correct.

Verified with a full browser run on the deployed image: the new visualiser app requests 4 application roles and its service principal carries 4 admin-consented grants. Using an app-only token from that app:

• places/microsoft.graph.room → 5 rooms returned (was 403)
• places/microsoft.graph.roomlist → 0 (no room lists defined in the sandbox, not an error)
• users, groups → still OK

Tenant isolation still holds: the demo domain's row was updated and all eight other tenant rows are byte-identical to the pre-run baseline.

Secret-expiry monitoring is deliberately left as-is for now — it needs Application.Read.All, and the minted secret doesn't expire until 2028-08-05.