fix(ingest): retire a day-precision row on the clock the app reads it on

Three parsers decide currency against ctx.now, because their page has no
"ongoing" heading worth trusting: bawiki.ts, and the Fate/Grand Order and
Infinity Nikki branches of fandom.ts. All three compared Date.parse(endsAt) to
now, and all three publish day-precision ends — so the comparison was against
the 00:00Z placeholder, which § Domain rules says is not an instant and nothing
may read literally.

clockFor already knows that and resolves such a boundary to the reset opening
that game-day on the reader's server. The parsers did not, so the feed retired
a row up to nine hours before the app, the countdown and the game all agreed it
was over. On the pinned Infinity Nikki fixture, "Inspiration Burst" left the
feed at 2026-08-22T01:00Z while clockFor still called it live for an American
reader until 09:00Z, and the page said it ran to 03:59 server time. The reader
does not see a stale row; they see the deadline they were counting down to
disappear on its last day, which is the silent drop this codebase treats as the
dangerous failure.

latestBoundaryMs answers clockFor's question for the last region rather than
one reader's, so a row is history only once it is history everywhere. It follows
a game's own server map and reset hour for the same reason clockFor does —
Endfield and Reverse: 1999 both move. Nothing stored changes: this is one
comparison, not a resolved boundary written into the feed, and no expected.json
moves.

Being generous by nine hours costs an expired row at the bottom of a list.
Being strict costs a live one.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

src/shared/time.ts

@@ -1,6 +1,7 @@
 import type { DisplayEvent, LaneId } from "./custom.ts";
 import { GAMES } from "./games.ts";
-import type { GameId, Precision, Region } from "./schema.ts";
+import { Region } from "./schema.ts";
+import type { GameId, Precision } from "./schema.ts";
 
 /**
  * Time is this product's entire subject, so the vocabulary lives in one place:
@@ -196,6 +197,39 @@ function boundaryMs(
   return dayStartMs(iso.slice(0, 10), region, event.game);
 }
 
+/**
+ * The instant a printed boundary has passed for **every** reader, whatever
+ * region they are on.
+ *
+ * `boundaryMs` above answers the question for one reader; this answers it for
+ * the last of them. The two must agree, because they are read at opposite ends
+ * of the same pipeline: an ingest parser deciding whether a row is still worth
+ * publishing, and the countdown deciding whether to call it over.
+ *
+ * They did not. A parser comparing `Date.parse(endsAt)` against `now` retires a
+ * day-precision end at UTC midnight — the placeholder, not an instant (§ Domain
+ * rules) — while the app keeps the event live until the reset that opens that
+ * game-day on the reader's own server. For a default server map that is 09:00Z
+ * in the Americas, so the feed drops an event nine hours before the app, the
+ * countdown and the game all agree it is over. The reader does not see a stale
+ * row; they see the deadline they were counting down to vanish on its last day,
+ * which is the silent drop AGENTS.md § Working on parsers calls the dangerous
+ * failure.
+ *
+ * So a row is history only once it is history everywhere. Being generous by a
+ * few hours costs an expired row at the bottom of a list; being strict costs a
+ * live one.
+ */
+export function latestBoundaryMs(
+  iso: string,
+  precision: Precision,
+  game?: LaneId,
+): number {
+  if (precision !== "day") return Date.parse(iso);
+  const day = iso.slice(0, 10);
+  return Math.max(...Region.options.map((r) => dayStartMs(day, r, game)));
+}
+
 export type Urgency = "expired" | "critical" | "soon" | "near" | "calm";
 
 /**