Add soft-delete for service variants

[jackfreem]

Problem

Backfila supports service variants (e.g. customermappings/playpen-jackf, customermappings/playpen-<ldap>) but there was no way to delete them once created. Stale playpen variants accumulate over time with no way to clean them up through the UI or API.

Solution

Adds reversible soft-delete for service variants. A deleted variant is hidden from all listings and detail views; if the variant later re-registers via configure_service, the soft delete is reversed in place (same row, history preserved).

Changes

Database

• Adds deleted_at TIMESTAMP(3) NULL column to the services table (v024__backfila.sql)
• Adds ServiceQuery.notDeleted() constraint using IS_NULL on deleted_at

Backend

• New DeleteServiceVariantAction: POST /services/{service}/variants/{variant}/delete
  • Requires users capability
  • Guards against deleting a variant that has running backfills
  • Returns 400 if the variant doesn't exist or is already deleted
  • Emits an AuditClient event attributing the deletion to the caller
  • Returns a 303 redirect back to the services index (it's the target of the UI form POST)
• Filters deleted variants from GetServicesAction, GetServiceVariantsAction, and GetServiceDetailsAction
• ConfigureServiceAction revives a soft-deleted variant in place (clears deleted_at on the existing row); deleted variants don't count toward the variant limit

UI

• Adds a "Danger Zone" section to the service info page (/services/{service}/{variant}/info) with a "Delete Variant" button and a confirmation dialog

Design decisions

• Soft delete only — preserves historical backfill run data that references the service_id FK, consistent with how backfill run deletion works
• Re-registration revives in place (changed per review) — the previous fresh-row approach collided with unq_registry_name_variant; reviving the existing row avoids that and keeps the variant's backfill history
• Block deletion if running backfills exist — prevents orphaning active work
• Audit via AuditClient rather than DbEventLog — event_logs.backfill_run_id is NOT NULL, so a service-level event doesn't fit that table without a migration

Testing

DeleteServiceVariantActionTest (runs against real MySQL with unq_registry_name_variant enforced) covers:

• Happy path deletion + audit event attribution
• Deleted variant hidden from services/variants listings while live variants stay visible
• 400 on non-existent or already-deleted variant
• 400 when running backfills exist
• Re-registration after deletion revives the same row (asserts the row id is unchanged and deleted_at is cleared)

Also verified end-to-end against a locally running BackfilaDevelopmentService:

• Info page renders the Danger Zone section
• Form POST soft-deletes the row (deleted_at stamped) and returns 303 to /services/
• Repeat POST returns 400; deleted variant's detail page shows the not-found error
• Full :service:test suite passes (113 tests)

[mpawliszyn]

A few observations and questions from a close read of the soft-delete change.

[mpawliszyn]

Re-registration 'fresh row' path vs. the unique key: the services table keeps UNIQUE KEY unq_registry_name_variant (registry_name, variant) from v016, and v024 did not alter it. When this lookup returns null for a soft-deleted variant and the code then session.save()s a new DbService with the same (registry_name, variant), the DB unique key may reject the insert. Only the re-registration test asserts the fresh-row behavior and nothing exercises it over HTTP — worth confirming the test DB actually enforces the unique key. Connects to the PR note: "Once the migration is run, I'll be able to test the remaining parts of this."

[mpawliszyn]

Consider making the soft delete reversible instead of creating a fresh row on re-registration. Reversing the soft delete (clearing deleted_at on the existing row) is likely what we actually want in the re-registration case: it revives the variant in place, preserves the existing service_id and its history, and sidesteps the (registry_name, variant) unique-key collision noted above (which the current "fresh row via session.save()" path risks hitting). This would replace the .notDeleted() exclusion in the upsert lookup with an un-delete on match.

[jackfreem]

Done, re-registration now clears deleted_at on the existing row instead of inserting a new one. This preserves the service_id and its backfill history and sidesteps the unique-key collision. The upsert lookup no longer excludes deleted rows, and deleted variants no longer count toward MAX_VARIANTS. The test now asserts the same row id survives a delete → re-register cycle (passes against real MySQL with the unique key enforced).

[mpawliszyn]

ServiceQuery.deleted() (Operator.IS_NOT_NULL) is added but has zero callers anywhere in this PR or the codebase — dead code as of this change. notDeleted() is used at five sites; deleted() at none. Either wire it to a use (e.g. an admin 'show deleted variants' view) or drop it to keep the query surface minimal.

[jackfreem]

Dropped deleted(). Could add it back alongside an admin "show deleted" view if that ever materializes.

[mpawliszyn]

softDelete(clock: Clock) takes the Clock as a parameter; it should use an injected clock instead of asking for one to be passed in. The caller (DeleteServiceVariantAction) already has a Clock injected and just forwards it here — pushing that injection down (or setting deleted_at directly at the call site, as SoftDeleteBackfillAction does) removes the passed-in parameter.

[jackfreem]

Removed softDelete(clock) from the entity. DeleteServiceVariantAction now sets deleted_at = clock.instant() directly at the call site. I kept the action's injected Clock (rather than Instant.now() as in SoftDeleteBackfillAction) for testability.

[mpawliszyn]

caller: ActionScoped<MiskCaller?> is injected but never used. It should be used to write a DbEventLog audit entry attributing the deletion to a user, matching the two closest siblings (SoftDeleteBackfillAction, CancelBackfillAction) which both log who performed the mutation. As written, a variant deletion leaves no record of who did it.

[jackfreem]

I went with AuditClient rather than DbEventLog: event_logs.backfill_run_id is NOT NULL, so a service-level event doesn't fit that table without another migration, whereas AuditClient is already the mechanism for run lifecycle audit events (AuditClientListener).

Deletion now emits an audit event with requestorLDAP = caller principal plus an app log line, and the test asserts the attribution via FakeAuditClient.sentEvents. Happy to widen event_logs instead if you'd prefer a durable in-DB record.

[mpawliszyn]

Following on the reversible-soft-delete suggestion in ConfigureServiceAction: this Danger Zone / Delete Variant UI may not be needed if soft delete is made reversible on re-registration. If re-registering a variant revives it in place, then the delete + re-register cycle handles the stale-variant cleanup without a dedicated UI affordance to trigger deletion. Worth deciding the reversible-soft-delete design first, since it determines whether this button is necessary.

[jackfreem]

I kept the button: revive-on-re-register handles resurrection, but there's still no other way to trigger a deletion, and cleaning up stale playpen variants is the point of the PR. The two compose nicely now, delete a stale variant, and if it ever re-registers it comes back with its history intact (so the confirm dialog no longer says "cannot be undone"... it can, by re-registering).

Separately, testing this against a locally running instance (I left Block after the layoffs) surfaced two bugs in the endpoint as reviewed: (1) misk's response-body claim check rejected the Unit return with a JSON @ResponseContentType at startup — the service wouldn't boot with this action installed; (2) the JSON @RequestContentType would have rejected the browser form's urlencoded POST. It now returns a 303 redirect back to the services index, matching the BackfillCreateHandlerAction idiom, and I verified the full flow (render → POST → 303 → variant hidden, second POST → 400) against a running dev instance.

[mpawliszyn]

Sure we need the initial button but I'm not sure we need the "can't be undone" piece.