abuse-enforcement-service: fail closed when the allowlist store errors

[Pitchfork-and-Torch]

Problem

In abuse-enforcement-service, the allowlist is the exemption check that runs before any enforcement rule can fire. A Manhattan GET failure during that check was swallowed inside ManhattanAllowlist::get_entity and returned as None. fetch_user_allowlist / fetch_entity_allowlist read None as is_allowlisted: false, so run_enforcement_inner continued into the rule pipeline for an account or post that may have been exempt.

The neighbouring Gizmoduck and credibility fetches on the same path behave differently: they abort with ? and the score is retried. Only the exemption lookup failed toward enforcement.

Change

Make the allowlist lookup behave like the other critical fetches.

• ManhattanAllowlist::get / get_entity return anyhow::Result<Option<_>>. Ok(None) means the store confirmed the key is absent. A GET error, or a stored entry that cannot be decoded, is returned as Err instead of None.
• fetch_user_allowlist / fetch_entity_allowlist return Result and propagate the error. Only a confirmed absence maps to "not allowlisted". Shared conversion lives in a small allowlist_facts helper.
• run_enforcement_inner uses ? on the allowlist lookups. A store error now aborts the attempt and the score lands in the existing retry queue (exponential backoff, MAX_RETRIES, then dropped without enforcing) instead of proceeding to rules.
• Admin handlers: GET /allowlist/{id} and GET /allowlist/{type}/{id} return 500 on a read error instead of 404 (OpenAPI responses updated). Bulk upsert reports a failed pre-read as a per-row error rather than guessing add. The DELETE audit before_json snapshot stays best-effort and never blocks the delete.

No change to behaviour when the store is healthy. No rule, config, or action changes.

Before / after

Scenario	Before	After
Allowlisted, store healthy	skip (user_in_allowlist)	skip (user_in_allowlist)
Not allowlisted, store healthy	proceed to rules	proceed to rules
Store GET fails	proceed to rules (could reach act_suspend)	Err → retry queue; never enforces on this attempt
Stored entry undecodable	proceed to rules	Err → retry queue

Tests

• Added unit tests in strato.rs for the lookup-to-facts conversion, including one asserting that a store error is not turned into is_allowlisted=false.
• This service depends on internal xai_* crates that are not in the repo, so it cannot be built here. The changed allowlist.rs / strato.rs code was compiled verbatim in a scratch crate against stubbed store/facts types (same tracing, anyhow, serde_json usage) and driven through a scripted store: 9/9 tests pass and the before/after table above is its output. Only Manhattan GET failed increments MANHATTAN_ERRORS_TOTAL; the decode-failure case does not.
• allowlist.rs and strato.rs are rustfmt-clean. Remaining rustfmt diffs in lib.rs / service.rs are pre-existing on main and untouched.

Upstream

The touched regions are identical on xai-org/x-algorithm main and this commit cherry-picks onto it cleanly. A full sync of this fork's main with upstream is not part of this PR: it conflicts in four files owned by the fork's own commits (README.md, home-mixer/candidate_hydrators/vf_candidate_hydrator.rs, home-mixer/params/param.rs, home-mixer/scorers/ranking_scorer.rs).