Build the session list pilot on the settled contract and measure it against the baseline

## Question

Does the settled contract actually deliver, on the real page, against the real backend?

Implement the contract from FR-3640 and FR-3641 on `ComputeSessionListPage` and its route entry in `react/src/routes.tsx`, on the router version FR-3638 concluded. Then re-run FR-3637's measurement **by the method it recorded**, so the numbers are comparable rather than merely both existing.

Report:

1. Before/after per segment, both in-app navigation and cold entry.
1. Whether the UX contract held: does the page shell still appear immediately with a skeleton, with no blank frame and no navigation stall?
1. Whether the refetch paths still work — filter, pagination, sort, type tab, manual refresh, and the poll — with no double-fetch. Watch the network panel, do not infer from the code.
1. What the contract got wrong. This is the point of the ticket: anything the spec did not anticipate is a finding, and the contract gets amended rather than quietly worked around.
1. Whether the shape generalises. Name what a second page would need that this one did not — that is the input to the follow-on rollout effort, even though the rollout itself is out of scope here.

Work on a branch; a prototype-grade result is fine as long as the measurement is honest. If the numbers do not move meaningfully, say so plainly and stop — that is a real answer and it changes the map, and shipping a null result is better than shipping a rewrite that bought nothing.

Map: FR-3636.

JIRA Issue: FR-3642

Start with FR-3638, FR-3640, and FR-3641, then inspect ComputeSessionListPage and its route entry in react/src/routes.tsx. Reproduce FR-3637's recorded measurement method for in-app navigation and cold entry, exercise every listed refetch path while watching the network panel, and report comparable results, contract gaps, and what a second page would require.

Written by the indexing model from the issue text.