fix(backend): harden get_caller_id and classify transport faults on the deletion lookups

[dmeiser]

Carries forward the two non-duplicate pieces of the now-closed #671 and #676. Neither is in main; both are small and independently testable, so they are split out rather than folded into the already-merged deletion work.

1. get_caller_id assumed identity is a mapping (from #671)

event.get("identity") or {} then .get("sub") raised AttributeError on a present-but-non-mapping identity — a string, a number, a list — because those are truthy. The caller then surfaced as the decorator's generic INTERNAL_ERROR rather than the typed UNAUTHORIZED the handlers raise for an absent caller.

>>> get_caller_id({"identity": "not-a-dict"})
AttributeError: 'str' object has no attribute 'get'

Everything else in #671 is already on main via #662 (same 31 files, same outcome: responses.py gone, the dead symbols pruned, the AST guard and behavioural UNAUTHORIZED check both present), which is why that PR was closed rather than merged.

2. The pre-delete Cognito lookups ignored transport faults (from #676)

Both _lookup_cognito_user_for_deletion and _find_cognito_user_by_sub caught ClientError only, so a BotoCoreError during the lookup escaped to lambda_handler — no attributed log line, no retry guidance. That is the wrong answer here specifically: the lookup runs before the sweep and before the Cognito delete, so nothing has been mutated and a retry converges. Both now catch (ClientError, BotoCoreError).

To classify that without adding a second definition of "transient", is_transient_cognito_error now takes a BaseException and counts a bare BotoCoreError as retryable (a transport fault is not a service verdict); the pre-delete catches just call it. COGNITO_TRANSIENT_ERROR_CODES remains the single set shared with retry_on_transient_errors.

The asymmetry this deliberately preserves

run_deletion_steps' post-sweep Cognito delete keeps its narrower isinstance(error, ClientError) guard, so #677's tested unknown-state contract is untouched: there the delete request has already been sent, so a transport fault leaves the Cognito state genuinely unknown and must not promise a retry. Same fault, opposite correct answer, because of where it happens. Both sides are now commented in the code and in the AGENTS.md #291 entry.

Tests

• test_cognito_transient_classification.py (new): every code in the set, a permanent code, a bare BotoCoreError, non-botocore exceptions, a ClientError with no Error block, plus a guard that the retry wrapper and the classifier cannot drift onto separate sets.
• test_caller_id_helper.py: non-mapping identities return None.
• Handler-level: a BotoCoreError lookup is RESOURCE_BUSY with a retry promise on both the self-service and admin paths, and the Cognito delete is never attempted.

Gates

pytest tests/unit — 1575 passed, 2 skipped, 100% coverage; xenon --max-average A --max-absolute B (the CI complexity gate), ruff check src/ tests/, and mypy src/ all clean.