fix(atproto): stop a failed enable from trapping crossposting on

[hm21]

Summary

• enable_user_atproto_with_trigger / reenable_user_atproto_with_trigger now roll the opt-in back to enabled=false when the control-plane trigger fails, instead of leaving enabled=true, state='failed'.
• disable_user_atproto_with_trigger completes the local disable when the trigger fails and the account has no DID. A provisioned account (DID present) still returns the error, unchanged.
• The lifecycle writes now carry the existing atproto_did forward instead of nulling it, so the DID that gates the disable above survives a failed enable.
• The web settings card keys its failure phase on the state alone, since a rolled-back enable no longer reports enabled=true.
• Tests: the existing enable-failure test now pins the rollback; new tests cover a provisioned enable failure (DID kept, disable still refused), the reenable rollback, and disabling a stuck unprovisioned account both directly and through set_user_atproto_crosspost.

Motivation

enable_user_atproto persists enabled=true, state='pending' before it calls the control plane, and on trigger failure the old code wrote enabled=true, state='failed'. That leaves an opt-in that exists nowhere except that row — no gateway record, no repo, no DID — while /api/user/atproto/status reports crossposting as on.

The second half is what makes it a trap rather than a cosmetic wrong flag: the disable path calls the control plane first and only writes disabled after it succeeds. So while the control plane is unavailable, the same outage that refused the enable also refuses the disable, and the account stays switched on with no way for the user to switch it off.

This is reproducible in production right now. In the mobile client (divinevideo/divine-mobile, Settings → Bluesky Publishing) the toggle reads as on with status "Account provisioning failed", and turning it off returns the scoped 503 from #281 ("Bluesky publishing is temporarily unavailable"). Verified on a real Samsung Galaxy against production login.divine.video; the handle it advertises (<username>.divine.video) resolves nowhere — no /.well-known/atproto-did, no _atproto TXT record, Profile not found from the public Bluesky API.

Design notes for review:

• Why roll back rather than keep the intent. If the trigger never reached the control plane, the intent exists only here and is safe to drop; the user can retry. If it did land before the response failed, provisioning reports back through internal_sync_atproto and the state converges there — so the rollback is self-healing in that race, whereas today's stuck flag is not.
• Why the disable escape hatch is gated on the DID. Without a DID there is no repo to publish from, so honouring "off" locally cannot produce a false "off". With one, refusing is correct: a live account could keep publishing while the user believes it is off. That boundary is the existing disable_trigger_failure_preserves_existing_state test, which stays green.
• Why the enable path stopped nulling the DID. set_atproto_state writes atproto_did unconditionally, and every lifecycle write passed None — so the enable path erased the exact signal the gate above depends on. An enable against an already-provisioned account, or a control-plane sync landing mid-write, left did=NULL with a live repo behind it, and the next disable would then take the unprovisioned path. Carrying the DID through is safe: a stale DID authorizes nothing on its own (ready_atproto_identity also requires state='ready'), and provisioning overwrites it through the internal sync.
• Known limit of the escape hatch. It is a local release, not a remote one. If the original enable did reach the control plane, a late internal_sync_atproto can report enabled=true and switch the account back on after the user turned it off — the mirror image of the convergence that makes the enable rollback safe. Recovering from that needs the gateway to be reachable again, which is the same condition that makes the normal disable work.
• Out of scope. Whatever is making DIVINE_SKY_ATPROTO_CONTROL_PLANE_URL (divine-handle-gateway) fail in production is an operational issue this PR does not touch — it only stops that outage from leaving accounts in an unrecoverable state. A durable retry queue for remote disables is likewise out of scope; the gateway remains the source of truth for the remote link.

Related Issue

• Closes #none

Testing

• cargo test --workspace --verbose — not run locally: this machine has neither Docker nor a local Postgres, and the ATProto suites need common::setup_test_db. Please let CI confirm the five touched tests in api/tests/atproto_http_test.rs.
• e2e/tests/bluesky-settings.spec.ts — not run locally (needs the Playwright stack); the fixture change is mock-only.
• cargo clippy --workspace --all-targets --all-features -- -D warnings -A deprecated — clean
• cargo fmt --all -- --check — clean
• cargo test -p keycast_api --lib — 190 passed
• cargo test -p keycast_api --test atproto_http_test --no-run — the new tests compile
• CI note: run 30899938228 first failed in test_suggest_users_for_admin_uses_the_email_trigram_index (keycast_core, untouched here). Re-running the identical commit passed; the plan assertion depends on ambient row counts and is tracked in test(core): email-trigram plan assertion depends on ambient row counts #335. Every test in this PR passed in both runs.
• Manual verification: reproduced the stuck state on a production account from the mobile client (see Motivation). The fix itself is not manually verified — it needs a deploy.

Visuals

• No visual change to the mobile client. In the keycast web card, an account whose enable failed now renders the existing "Failed" state (badge, last-error text, retry button) instead of the plain enable card — no new UI.
• Visuals and text avoid sensitive external brand or partner names unless explicitly approved

[dcadenas]

✅ The rollback and the DID-gated local release are the right shape, and the interleaving tests pin them properly.

Three gaps remained around the pre-trigger write. I pushed fixes rather than handing them back; detail is inline.

Changes I pushed

• The opt-in write no longer reads atproto_did and writes it back — it omits the column, so there is no window for a provisioning sync to be overwritten.
• A confirmed ready account is now excluded from that write, so a redundant enable during an outage cannot report a publishing account as switched off.
• A rollback that lands now revokes ATProto OAuth sessions, matching the invariant the local-release test states.

The ready exclusion is the widest of the three: enabling an already-ready account now returns current status without calling the control plane. pending stays eligible, so a stuck opt-in can still be retried.

Checks

• cargo fmt --all -- --check and cargo clippy --workspace --all-targets --all-features -- -D warnings -A deprecated
• cargo test --workspace, plus the integration-tests suites for core, api and signer
• cargo test -p keycast_api --test atproto_http_test: 35 passed
• cargo build --release --workspace
• CI is green on the pushed head.

The two behaviour changes are pinned by tests that fail when the fix is removed — I removed each one and confirmed only the matching test failed. The two DID tests are regression guards, not race reproductions; the window they close has no seam to interleave into, and the fix removes it structurally rather than detecting it.

enable_failure_keeps_the_did_so_disable_still_refuses now seeds pending with a DID instead of ready, because the ready exclusion short-circuits before the trigger runs. Its intent and assertions are unchanged.

Merge stays with you.