GET /api/v1/user/assigned carries an ETag and answers a repeat with 304 until something assigned to the viewer changes #9185

GET /api/v1/user/assigned now carries a weak ETag, and a repeat that holds it gets a 304 with no body. The new test file and the five existing suites that touch this route pass. The gate script and bun x tsc --noEmit printed nothing; I didn't check their exit codes.

• What changed: In src/http/api/user.ts, the 200 answer carries etag (from weakEtag, computed over the rendered body), cache-control: private, no-cache and vary: authorization, cookie. If If-None-Match holds that tag, the answer is a 304 with the same three headers and no body. The body itself is unchanged, and src/http/api.ts is untouched.
• Auth paths: A request with no session or with a token short of ro returns before the tagging code, so it behaves as before and carries no ETag. The test covers a missing token and a bad token, but not a valid token below ro, because I found no token scope below ro to use.
• Why the tag moves: The tag is a hash of the viewer's own list, so assigning, unassigning, retitling or closing an issue changes it. Two users with different lists get different tags, and one user's tag does not match for the other.
• Tests: test/assigned-etag.test.ts has five tests: the headers, the 304 with the security headers, each kind of change moving the tag, two users not sharing a tag, and the unauthenticated cases. I did not run the new tests against the old code to confirm they fail without the change.
• Not run: I ran the new test file and the five suites above, not scripts/fast.ts. It named 1101 files, far over its budget, so I picked the suites that reference this route myself.

To try it: curl -si -H "authorization: Bearer $TOKEN" $FORGE_URL/api/v1/user/assigned shows the etag. Repeat the request with -H 'if-none-match: <that etag>' to get the 304.

Closes #9177

GET /api/v1/user/assigned now carries a weak ETag, and a repeat that holds it gets a 304 with no body. The new test file and the five existing suites that touch this route pass. The gate script and bun x tsc --noEmit printed nothing; I didn't check their exit codes.

• What changed: In src/http/api/user.ts, the 200 answer carries etag (from weakEtag, computed over the rendered body), cache-control: private, no-cache and vary: authorization, cookie. If If-None-Match holds that tag, the answer is a 304 with the same three headers and no body. The body itself is unchanged, and src/http/api.ts is untouched.
• Auth paths: A request with no session or with a token short of ro returns before the tagging code, so it behaves as before and carries no ETag. The test covers a missing token and a bad token, but not a valid token below ro, because I found no token scope below ro to use.
• Why the tag moves: The tag is a hash of the viewer's own list, so assigning, unassigning, retitling or closing an issue changes it. Two users with different lists get different tags, and one user's tag does not match for the other.
• Tests: test/assigned-etag.test.ts has five tests: the headers, the 304 with the security headers, each kind of change moving the tag, two users not sharing a tag, and the unauthenticated cases. I did not run the new tests against the old code to confirm they fail without the change.
• Not run: I ran the new test file and the five suites above, not scripts/fast.ts. It named 1101 files, far over its budget, so I picked the suites that reference this route myself.

To try it: curl -si -H "authorization: Bearer $TOKEN" $FORGE_URL/api/v1/user/assigned shows the etag. Repeat the request with -H 'if-none-match: <that etag>' to get the 304.

GET /api/v1/user/assigned now carries a weak ETag, and a repeat that sends it in If-None-Match gets a bodiless 304. The check failed only because no commit message had a Try: line. I pushed an empty commit that has one, and bun scripts/gate.ts now prints nothing. I did not run the tests again. The code is unchanged since the last push, and the new tests and the five existing suites that touch the route passed then. The forge's check will run on this push.

• Change: The route in src/http/api/user.ts answers 200 with etag (from weakEtag over the body), cache-control: private, no-cache and vary: authorization, cookie. A matching If-None-Match gets a 304 with the same headers and no body.
• Tag changes: The tag covers the viewer's own list. It moves when an issue is assigned to or taken off them, or when an assigned issue is retitled or closed. Two users with different lists never share a tag.
• Unchanged paths: Requests with no session or a bad token behave as before and carry no ETag. I found no token scope below ro to test, so that case has no test of its own.
• Tests: test/assigned-etag.test.ts has five tests. I did not run them against the old code to confirm they fail without the change.
• Left alone: src/http/api.ts, and the response body.

Try: call GET /api/v1/user/assigned on the preview with a token. Repeat it with the returned etag in If-None-Match and expect a 304.