GET /api/v1/repos/:owner/:name/issues/:number carries an ETag and answers a repeat with 304 until the issue changes #9143

Intent: an agent watching one issue (its state, assignee, labels or plan) polls for an empty 304 instead of the whole issue, as the issues list (#9120) and its comments (#9134) already allow.

Today the route in src/http/api/issues.ts (~line 216) answers with no etag; the list route in the same file shows the pattern.

Done looks like:

• [x] The 200 carries a weak etag from the exact JSON sent, cache-control: private, no-cache and vary: authorization, cookie (a sealed issue is for some readers only).
• [x] A matching If-None-Match answers 304 with no body and the same tag; closing, retitling, assigning, labelling or commenting each change the tag and the answer is 200.
• [x] Access is checked before tags are compared: a stranger asking for a sealed issue is refused whatever tag they hold.
• [x] A test in test/ covers 200 then 304, a comment giving 200 with a new tag, and the stranger's refusal.
• [x] The route's OpenAPI description names the etag header and the 304.

Files: src/http/api/issues.ts, its OpenAPI route file, one test. Risk: the issue body embeds its comments; the tag must change when a comment is added or edited.

Reviewed pull #9150 at its head: ticked The 200 carries a weak etag from the exact JSON sent, cache-control: private, no-cache and vary: authorization, cookie (a sealed issue is for some readers only).; A matching If-None-Match answers 304 with no body and the same tag; closing, retitling, assigning, labelling or commenting each change the tag and the answer is 200.; Access is checked before tags are compared: a stranger asking for a sealed issue is refused whatever tag they hold.; A test in test/ covers 200 then 304, a comment giving 200 with a new tag, and the stranger's refusal.; The route's OpenAPI description names the etag header and the 304..