fix(gameserver): percent-encode ServerDB URI query values (#41)

[thesprockee]

Summary

• Closes gameserver: legacy ServerDB URI embeds discord_id and password unescaped #41: TWO raw-concatenation sites, not one — the legacy ServerDB URI (gameserver.cpp) and the websocket bridge's URL-credential path (ws_bridge.cpp:997-1004, same target endpoint, same nevr_discord_id/nevr_password config values, found by the Opus review of the first commit). Both built ?discord_id=%s&password=%s-style query strings via snprintf/string concatenation with no escaping.
• A password containing a&guilds=999#tail injects its own guilds parameter and truncates the real one into the URL fragment (which ixwebsocket drops). Reproduced exactly against both sites with a hostile mutant value.
• Fix: new src/runtime/server/serverdb_uri.{h,cpp} with pure functions (BuildLegacyUri, BuildTokenRouteUri, BuildBridgeCredentialUri) that RFC-3986-percent-encode every value via libcurl's curl_easy_escape. guilds/regions encoded element-by-element with literal commas preserved (server splits on comma). Bridge path keeps its existing all-or-nothing behavior (both discord_id and password, or neither).
• New just-verify sensor forbids the old raw-concatenation patterns reappearing in either file, and requires both builder functions to actually be called at their respective sites.
• Password is never logged on either path.

COMPATIBILITY RISK — needs your decision, not addressed in this PR

Nakama sets an account's stored password from this URL parameter on the FIRST login that supplies one (evr_pipeline_login.go:472-475, only when the profile has no password set yet). Before this PR, both paths sent the password unencoded. Of the special characters, only +, a valid %XX escape, and &/# truncation that still leaves 8+ bytes can produce a MANGLED value actually stored server-side (+ becomes a space, %XX is decoded, everything after &/# is cut off). A bare ; does NOT produce a stored mismatch — Go's parseQuery drops the whole pair, so the password was never set via this path at all (confirmed by independent re-review); same for an invalid % escape, or truncation short enough that nakama's own LinkEmail minimum-length check rejects it outright — those accounts never got a password stored this way and this PR lets them set one for the first time. Nakama also keeps only the first 32 bytes of the decoded password (session_ws.go:181), so mangling past byte 32 never caused a mismatch either. After this PR the client sends the correct, fully-encoded password, which won't match a genuinely-mangled stored value from the +/%XX/&/# cases above — those accounts would fail to authenticate. Passwords using only letters/digits/-._~ are unaffected. Can't tell how many accounts are affected without the production database.

Test plan

• 15 tests in test_serverdb_uri.cpp (11 original + 4 for the bridge path): exact encoding, round-trip via libcurl's parser, password-can't-inject-a-parameter, bridge-and-ServerDB-paths-decode-identically for the same hostile value, server-accepted values unchanged, all-or-nothing credential behavior preserved
• Red/green: reverting the encoder to a no-op fails the injection tests on both sites, reproducing the exact corrupted/truncated query string
• just verify green (capped CMAKE_BUILD_PARALLEL_LEVEL=4), including after merging current main (5393834)
• Independent Opus re-review of the bridge-path fix: PASS

Found, not fixed here

• ws_bridge: stripping format=evr for matchmaker connections can concatenate the path and query #116: stripping "format=evr&" for matchmaker connections can concatenate path and query with no separator if format=evr happens to be first in the query string — pre-existing, latent with the current example config
• docs: stale token-auth-migration.md citation at gameserver.cpp:1232 #110: stale doc citation at gameserver.cpp:1232

Not done

• No live server run — covered by unit tests + just verify only, not an end-to-end registration/bridge-connect against the real game service.

🤖 Generated with Claude Code