fix(ui): prevent stale page keys on back navigation

[linkdata]

Summary

• always replace ui.Handler's Cache-Control value with no-store before rendering any response
• document the same requirement for custom handlers that emit HeadHTML or equivalent request-key metadata
• cover successful and pre-output failure responses with regression tests

Rationale

JaWS page HTML contains a one-use Request key. If Back navigation reconstructs a page from an HTTP-cached response, that page retries the consumed key and the WebSocket endpoint returns 404.

Reloading specifically for that 404 is not available to browser code: the WebSocket API deliberately does not expose enough opening-handshake failure information to distinguish it from other connection failures. Marking the page response no-store instead prevents an HTTP cache from reusing the stale capability. The existing persisted-pageshow reload remains the separate fallback for bfcache restoration.

References:

• https://websockets.spec.whatwg.org/#feedback-from-the-protocol
• https://www.rfc-editor.org/rfc/rfc9111.html#section-5.2.2.5

Compatibility

ui.Handler unconditionally replaces any existing Cache-Control value with no-store, including when its template omits HeadHTML. This is intentional: ui.Handler is the full-page helper and caching a response that may contain a one-use key is not safe. There is no opt-out.

Custom page handlers must include the no-store directive themselves. Responses already cached before deployment are not repaired retroactively and may fail once until refreshed. POST history entries retain the browser's normal resubmission behavior.

Verification

• go generate ./...
• go vet ./...
• gofmt -l .
• gofumpt -l .
• staticcheck ./...
• golangci-lint run
• gosec ./...
• go build ./...
• JAWS_REQUIRE_NODE=1 go test -race ./...
• JAWS_REQUIRE_NODE=1 go test ./...

The optional 386 test binaries cannot execute on this arm64 host (exec format error); the repository's build-386 CI job remains the verification leg for that architecture.