fix(assets): delay connection-loss recovery

[linkdata]

Summary

• wait five seconds after a WebSocket failure before the first readiness probe
• show the connection-lost banner only when that probe does not trigger an immediate reload
• use the reconnect state as the cancellation guard, so pagehide makes delayed timer and XHR callbacks inert
• add Node-backed regressions for the grace boundary, duplicate failure events, probe outcomes, scroll preservation, and the failure-before-pagehide race

Behavior and tradeoffs

This is intentionally a fixed grace-period heuristic, not navigation tracking.

• A genuine connection loss takes five seconds longer to probe. If the first probe stalls until its ten-second timeout, the banner can appear roughly 15 seconds after failure.
• A refresh, redirect, or cross-document form GET/POST that commits within five seconds remains quiet. If it leaves the old document active longer, the old page can still show the banner or be superseded by a reconnect-triggered reload before pagehide.
• Background fetch/XHR work is not navigation and is unaffected unless the WebSocket independently fails.
• The existing 60-second minimum page age and elapsed-time backoff remain. After a failure on a fresh page, healthy probes can occur around 5, 10, 20, 40, and 80 seconds before reload is allowed.

Testing

• node --check lib/assets/jaws.js
• go vet ./...
• gofmt -l .
• staticcheck ./...
• golangci-lint run
• gosec ./...
• go build ./...
• go test -race ./...