fix(cache): bound grace windows, cap render queues, and drop the useless estimate

Follow-up to f81b114b, addressing the three ways that commit could make things
worse rather than better. All three were verified against the real database or
by breaking the test and watching it fail.

- The grace window is now capped at 120s. A window is a cushion for the TTL
  boundary, not a second TTL, but the call sites treated it as the latter: the
  5 min values/staff routes and the 10 min teams route asked for a window as
  long as or longer than their own TTL, so a single large staleMs silently
  doubled how far behind a value could be served. Nothing marked those as
  unsafe, because nothing looked wrong. The cap lives in the cache rather than
  at the call sites so no future route can reintroduce it. Routes that asked
  for less than 120s (the 10s online poll, the 20s news cache) are unchanged,
  so their intended cushion still does its job.

- A request no longer queues behind an arbitrarily old render. Sharing a render
  is what collapses a cold-cache stampede into one render, but a hung render
  used to hold up everyone who arrived after it. A newcomer past 2s now serves
  the placeholder instead of waiting, reusing the ImagerUnavailableError path
  that "both upstreams down" already takes. The caller that actually started
  the render keeps waiting, which is correct: it is the one whose image this
  is. When the join window is removed the new test hangs for the full 10s it
  was meant to prevent, which is the tail this bounds.

- The information_schema row-count estimate is gone; the counters are exact
  again. Running it against the live database: users 165, rooms 92, camera_web
  0, and the estimate was 0.00% off on all three. At 165 rows an index scan is
  cheaper than the extra round trip the estimate needed, so the optimisation
  bought nothing and traded a guaranteed-correct member count for an
  approximation that InnoDB would only make less accurate as the table grows.
  The exactness is now pinned by tests: a real zero stays zero, a database
  error propagates instead of becoming a number, and each counter counts the
  table it claims to. The module stays, because the homepage and the boot
  warm-up writing different values to the same cache key is its own bug.

The module comment records the measured numbers, because "COUNT(*) is too slow"
sounds true in the abstract and is false here.

3223 tests pass.

src/lib/cache.test.ts

@@ -177,4 +177,34 @@ describe("cached (stale-while-revalidate)", () => {
 			expect(await cached(key, 20, fn, { staleMs: 10_000 })).toBe("recovered"),
 		);
 	});
+
+	it("caps the grace window so a large staleMs cannot hide staleness", async () => {
+		// A grace window is a cushion for the TTL boundary, not a second TTL. Left
+		// unbounded, a 1s TTL paired with a 10 minute window serves data 10 minutes
+		// old, which is invisible in the code and only shows up as a support
+		// ticket. The ceiling keeps that bounded no matter what a call site asks.
+		vi.useFakeTimers();
+		try {
+			const options = { staleMs: 600_000 };
+
+			// Inside the capped window the value is still served without recomputing,
+			// so the cushion itself is not lost.
+			let warm = 0;
+			const warmFn = async () => ++warm;
+			await cached("cap-warm", 1_000, warmFn, options);
+			await vi.advanceTimersByTime(119_000);
+			expect(await cached("cap-warm", 1_000, warmFn, options)).toBe(1);
+
+			// Past the ceiling the value is recomputed even though the caller asked
+			// for a 10 minute window. No prior stale read on this key, so nothing is
+			// in flight to short-circuit the recompute.
+			let capped = 0;
+			const cappedFn = async () => ++capped;
+			expect(await cached("cap-hard", 1_000, cappedFn, options)).toBe(1);
+			await vi.advanceTimersByTime(121_000);
+			expect(await cached("cap-hard", 1_000, cappedFn, options)).toBe(2);
+		} finally {
+			vi.useRealTimers();
+		}
+	});
 });