fix: govulncheck

[joe0BAB]

No description provided.

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

This PR is a govulncheck-driven dependency bump of golang.org/x/crypto, golang.org/x/net, golang.org/x/sys, and golang.org/x/text. Two findings in newly-added vendored code were identified after direct source inspection. Findings 3 and 4 from the initial draft were dismissed: the priority scheduler change only adds a build-tag gate on pre-existing logic (line 113 is unchanged), and server_wrap.go is guarded by //go:build go1.27 which is unreachable on this project's go1.25.10 toolchain.

⚠️ Note: The verifier agent returned a malformed response and could not complete automated verification. Findings below are based on direct diff inspection.

[docker-agent]

[MEDIUM] Missing base64 decoding in ParseByteSequence

ParseByteSequence strips the RFC 9651 colon delimiters but returns the raw base64-encoded ASCII characters as []byte instead of decoding them:

// Current (line 492-496):
func ParseByteSequence(s string) (parsed []byte, ok bool) {
    if _, rest, ok := consumeByteSequence(s); !ok || rest != "" {
        return nil, false
    }
    return []byte(s[1 : len(s)-1]), true  // ← returns raw ":aGVsbG8=:" stripped to "aGVsbG8="
}

RFC 9651 §4.1.8 specifies that byte sequences are base64-encoded between colons. A caller expecting ParseByteSequence(":aGVsbG8=:") to return []byte("hello") will instead receive []byte("aGVsbG8=") (the raw base64 ASCII). The fix is to run base64.StdEncoding.DecodeString(s[1:len(s)-1]) and propagate decode errors as ok=false.

This is newly-added code in this PR (new file httpsfv.go). While it is vendored upstream code, any callers within this repo that rely on this function will receive incorrect binary data.

[docker-agent]

[LOW] ParseDictionary silently accepts missing comma separators (RFC 9651 §4.2.2)

The comma separator between dictionary members is treated as optional:

// Lines 245-255:
if s[0] == ',' {
    s = s[1:]
}
s = s[countLeftWhitespace(s):]
if len(s) == 0 {
    return false
}
// loop continues — no error if comma was absent

RFC 9651 §4.2.2 requires members to be separated by OWS "," OWS. Input like "key1=1 key2=2" (space but no comma) will be parsed as valid, silently accepting malformed headers. This could mask upstream encoding bugs or enable header injection in edge cases.

This is newly-added code in this PR (new file). Upstream issue if confirmed, but worth noting for any internal callers.