feat(rustd): an event ends at the gate that refused it, once and only once

`UPDATE_FLEET_EVENT_FAILURE` has been collected since the statements landed and
had no caller. This is it: the other end of the row `record_received` opens,
and the last write §2's admission pass needs before it can be composed.

It lives beside the insert because the guard that makes the ending safe is a
statement about the OPENING — the update fires only on a row still in the
status the insert wrote — and a reader checking that predicate should find both
halves of it in one file.

`Ended` is a named type rather than a bool for the reason `Delivery` is one:
zero rows affected looks like failure and is not. It means the event was
ALREADY terminal, which is what a refused delivery whose acknowledgement was
lost looks like on its second pass. The refusal stands, the acknowledgement is
still owed, and the caller proceeds — it just must not report that pass as
having decided anything.

Three integration tests, run against live Postgres and PASSING:

- a refusal ends the event and its label and instruction land on the row;
- **a terminal row is never reopened.** A second refusal under a different
  label answers `Ended::Already` and the FIRST label still stands. Without the
  `status = 'received'` predicate, an event a human denied would come back
  carrying a billing refusal instead — silently, because nobody re-reads a
  label they already actioned;
- a refusal carrying no instruction stores SQL NULL, not `''`. An empty string
  passes every `IS NOT NULL` check and renders as a blank instruction, which
  reads as "we have nothing to tell you" rather than "there was nothing to
  tell".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>