Upgrade to upstream v1.13.2 (token revocation hardening)

[HerrSammyDE]

Brings the fork up to upstream pterodactyl/wings v1.13.2 (28af6dd).

Upstream v1.13.2

v1.13.2 is a single functional upstream commit — 28af6dd "update token validation" — sitting directly on top of v1.13.1. The release branch's ef2280b "ci(release): bump version" was deliberately not merged: the fork injects system.Version via ldflags and system/const.go stays develop (same as the v1.13.1 merge).

It is a security fix for the one-time JWTs:

• Revocation checking was extracted out of WebsocketPayload.Denylisted() into a shared isDenylisted() helper and is now applied to the backup-download, file-download and file-upload tokens as well. Previously those three only checked IsUniqueRequest() + scope, so revoking a user's access to a server did not invalidate already-issued download/upload tokens.
• New user_uuid claim on FilePayload, BackupPayload and UploadPayload.
• Denylist comparison tightened from Before(t) to !After(t) — a token issued in the same second as the revocation is now denied.
• New upstream suite router/tokens/denylist_test.go (6 tests).

Merged without a single conflict. Unusual for this fork, but the commit only touches router/tokens/** plus three one-line guards in router_download.go / router_server_files.go, and our edits to those two files (module rename, activity logging) sit elsewhere. git diff --name-status 28af6dd HEAD confirms websocket.go, file.go, backup.go, upload.go and denylist_test.go are byte-identical to upstream.

Deployment order: Panel before Wings

isDenylisted() fails closed — a token missing iat, server_uuid or user_uuid is rejected outright. user_uuid is new in v1.13.2, so backup downloads, file downloads and file uploads only work against a Panel that puts that claim into the JWT. Against an older Panel every such request returns 404 "The requested resource was not found on this server."

FORK_CHANGES.md

• Baseline rebased onto v1.13.2 (28af6dd), last-reviewed date updated.
• Section 4 gained three rows so the next upgrade does not mistake the v1.13.2 token hardening for fork code, plus the Panel-coupling callout above.
• Documented a merge trap found while reviewing: our server/filesystem/archive_test.go was replaced wholesale with tests for the fork-only archive_restore.go, and upstream's TestArchive_Stream lives in archive_stream_test.go. Upstream edits to archive_test.go therefore land in the wrong file on merge without any conflict to warn us.

Verification

Go is not installed on the dev host, so build and tests were run in a golang:1.24 container against the working tree:

• go build ./... — clean.
• go test ./... -count=1 — all packages pass, no failures.
• go test ./router/tokens/ -v — all 6 new denylist tests pass.
• go vet ./... — 4 pre-existing findings (unreachable code, copies lock value) in files this merge does not touch; nothing new introduced.

CI (go test -race) is the final gate.