This is EVIDENCE, not a verdict. It does not evaluate risk. To learn whether
an account has tripped any fraud rule, call `evaluate_fraud_rules` - reading
these rows and forming your own opinion is exactly what this server is built
to prevent.

Returns an error envelope (`ok: false`) for unknown accounts or an out-of-range
`days`. A successful response with zero transactions carries an
`empty_result_guidance` block explaining what the emptiness does and does not
imply; read it before drawing any conclusion.

THIS IS THE AUTHORITATIVE RISK VERDICT. The engine is deterministic: the same
account always yields the same result. Do not second-guess it, re-derive it
from raw transactions, or soften it.

Rules evaluated: VELOCITY_BURST, AMOUNT_SPIKE, NEW_GEO_HIGH_VALUE, STRUCTURING,
SHARED_DEVICE, IMPOSSIBLE_TRAVEL, DORMANT_REACTIVATION.

Covers, in plain terms: transaction velocity and card testing, spending
anomalies against the account's own baseline, unfamiliar geography, money
laundering by structuring or smurfing below a reporting threshold, account
takeover and credential stuffing via shared devices, and cloned cards
(impossible travel). Use this tool for ANY question about whether an account
is risky, compromised, laundering, or worth escalating - not only questions
phrased around velocity.

Every rule returns one of three states, and the difference matters:
  FIRED     - the threshold was met; `evidence_txn_ids` lists the transactions.
  NOT_FIRED - evaluated, threshold not met. This is a genuine pass.
  SKIPPED   - could NOT be evaluated (e.g. too little history for a baseline).
              This is an UNKNOWN, not a pass. Report skipped rules explicitly.

Each result carries the thresholds that were applied and the observations
measured against them, so any verdict can be recomputed by hand later. Cite
`rule_id` and `evidence_txn_ids` in anything you write.

Call this BEFORE flag_case. Takes no time window: each rule applies its own
documented lookback.

Use this to pivot from one compromised account to the others driven from the
same machine - the standard way an account-takeover ring is mapped. Pay
attention to `distinct_accounts_with_events`, `failed_login_count`, and
`password_reset_count`: a device with many accounts, failed logins, and resets
is a takeover tool, not a shared family tablet.

Returns an error envelope for unknown or malformed device ids.

Call this only after `evaluate_fraud_rules`, and only when you can cite the
rule ids that fired. The response includes an `audit` block that independently
re-runs the rules engine and compares your submission against it: if you cite
rules that are not firing, omit rule ids entirely, or set a severity the engine
does not support, the case is still recorded but flagged with warnings for the
human reviewer.

Not idempotent - each call creates a new case. Do not retry on success.