[linkdata]

Summary

• Keep the existing JaWS session and cookie on login by default. Re-login retains application data and emits LoginEvent; separately configured providers retain their own authentication. Logout continues to clear authentication in place.
• Add Server.RotateSessionOnLogin for deployments with a concrete session-fixation path. Opting in retains the previous new-session behavior and its spare-session-slot requirement.
• Hold protected routes and CurrentClaims behind the pending login event, so a hook can revoke a login before other requests use its claims. Reload active JaWS pages after the event completes. Keep application logger callbacks outside the login lock.

Why

JaWS binds sessions to the effective client IP, including trusted proxy headers when configured. Rotation helps only when an attacker can make a victim use a known pre-login cookie, reach JaWS from the same effective IP, and cannot obtain the later cookie. It does not help against control of the browser or post-login traffic. The default avoids replacing application session data and requiring a spare slot at login.

The HTTPS cookie-prefix change in linkdata/jaws#544 narrows ordinary cookie planting paths. The code changes are independent; merge this PR before JaWS #544 because its AI guidance describes the new jawsauth API. JaWS v0.902.0 still uses unprefixed HTTPS cookies; the __Host- protection applies after JaWS #544 is released and adopted. Applications should enable rotation whenever they have a concrete cookie-planting path, including on plain HTTP.

Verification

• go test -race -timeout=120s ./... (root module)
• go test -race -timeout=300s ./... (cmd module)
• go vet ./..., staticcheck ./..., golangci-lint run, and gosec ./... in both modules
• gofmt -l . and git diff --check