Trigger Deployment

Manual trigger — bypasses EventBridge; SQS for classic, a command row for shard.

Two transports, chosen by the deployment's recorded shard_map route (consume-at-scale O.20, V258):

• shard — the fleet owns this deployment's bars and eval-worker's queue is the wrong arm. The trigger is a strategy.eval_commands row written on THIS request's transaction (it lands or rolls back with the 202), announced by V258's NOTIFY at commit, consumed by the owning shard with today's snap semantics. No SQS message is sent.
• anything else (classic, or no row — a slow/irregular clock that never faced the check) — the SQS message, byte for byte as before.

override=true additionally allows the eval to persist a run for a bar that ALREADY has one. Without it, a trigger fired between bars recomputes the pipeline, lands on the same completed bar, and is correctly deduped by uq_signal_runs_strategy_time — which is why a daily strategy appears to "do nothing" when triggered after its bar has run.

The override loosens NOTHING else. Authorization, LIVE status and the account-mode freshness check below all still apply, and the ordinary dedup still covers every non-override run. A single trigger_override_id is minted here and carried on the message so at-least-once redelivery cannot turn one request into two executions (V68).