Reduce full-index work on context and unchanged refresh requests

Problem/Motivation

Alpha3 narrows comment, branch, and delivery loading, but context and refresh still load and access-check the full discussion. A small context response therefore has server cost proportional to the whole thread. An unchanged refresh returns 304 only after full-index construction.

The smaller context window and reduced refresh payload are useful improvements, but they do not establish a corresponding reduction in indexing time. This is remaining performance work, not evidence that alpha3 retained the exact latency measured before those changes.

Steps to reproduce

1. Request one context fragment from a large discussion and count hydrated comments and access checks.
2. Fetch refresh metadata, then repeat with its ETag while content is unchanged.
3. Observe full-index construction before the small context response or 304.

Proposed resolution

• Measure indexing and rendering separately on small and large threads.
• Reduce context hydration to the required accessible structure and rendered slice.
• Make unchanged refresh cheaper without bypassing current viewer/access validation or acknowledgement-token renewal.
• Preserve full ancestor access checks and correct depth, counts, order, and sibling-position metadata.

Remaining tasks

• Agree the approach after the conditional-refresh correctness issue is resolved.
• Record entity-load/access-check counts and cold/warm timings on a real 200+ comment thread.
• Test inaccessible ancestors and changes to viewer-dependent access without a comment edit.
• Document remaining breadth-dependent costs rather than claiming a fixed ceiling for arbitrary tree shapes.

The missing filter render cap and early query rejection remain on #3623173. Filter-wide search optimization, if justified by measurement, should be scoped separately.

User interface changes

Faster context loading and less server work during unchanged polling, with unchanged access and reading behavior.

API changes

To be determined by the chosen index/metadata strategy; preserve existing client behavior or document coordinated changes.

Data model changes

None prescribed; evaluate separately if the chosen approach needs persistent metadata.