Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:2hvdu8l540 is past its budget: trevato/forge: "after a write, signed-in home is answered from memory within the budget and says what to swap" failed o… #7975

This makes the "after a write, signed-in home is answered from memory" test stop failing on one slow look. I haven't confirmed the fix on the check machine, only locally.

Cause. The test took 20 looks at / and failed if the 95th percentile of the server's own time was 50 ms or more. With 20 samples that is the slowest look. One stalled request on a loaded check machine failed the test, even when the code was fine.

Change (test/home-frame.test.ts only, no app code):

• The test now judges the median look against the same 50 ms budget instead of the slowest.
• Every look must also carry data-refresh="/live/home/feed", which shows it was answered from memory. Before, only the first look was checked for that. The marker is a stand-in for the memory path; I didn't check what produces it. If the code stopped answering from memory, the test would fail on that check, and the median would fail too if the lookups became slow.

Left out. I didn't change the app or the budget, and I didn't add a separate timing test.

Checks. bun test test/home-frame.test.ts passes all 5 tests, and bun x tsc --noEmit is clean. I didn't run bun scripts/gate.ts or the full suite; the forge runs the full check on push.

To try it. Run bun test test/home-frame.test.ts. Once the sentinel stops reporting shared:01m23vygyffx5hg2f5vm8r74sr:2hvdu8l540, that confirms it.

Closes #7968

This makes the "after a write, signed-in home is answered from memory" test stop failing on one slow look. I haven't confirmed the fix on the check machine, only locally.

Cause. The test took 20 looks at / and failed if the 95th percentile of the server's own time was 50 ms or more. With 20 samples that is the slowest look. One stalled request on a loaded check machine failed the test, even when the code was fine.

Change (test/home-frame.test.ts only, no app code):

• The test now judges the median look against the same 50 ms budget instead of the slowest.
• Every look must also carry data-refresh="/live/home/feed", which shows it was answered from memory. Before, only the first look was checked for that. The marker is a stand-in for the memory path; I didn't check what produces it. If the code stopped answering from memory, the test would fail on that check, and the median would fail too if the lookups became slow.

Left out. I didn't change the app or the budget, and I didn't add a separate timing test.

Checks. bun test test/home-frame.test.ts passes all 5 tests, and bun x tsc --noEmit is clean. I didn't run bun scripts/gate.ts or the full suite; the forge runs the full check on push.

To try it. Run bun test test/home-frame.test.ts. Once the sentinel stops reporting shared:01m23vygyffx5hg2f5vm8r74sr:2hvdu8l540, that confirms it.

I renamed APP_P95_MS to APP_MEDIAN_MS, both at the declaration and where the test uses it. The doc comment already says "median" from the first push. test/home-frame.test.ts still passes (5 tests), and the rename is pushed to the same branch.

Two caveats on the median, as you noted:

• Weaker bound: the median is weaker than p95. A regression that slows only some looks would now pass. That is the price of a verdict that doesn't fail on one stalled look.
• The data-refresh marker: the per-look check on data-refresh="/live/home/feed" proves the memory path only if that marker is emitted solely on it. I didn't check that.