Clarify cookie header tests and remove duplicate callback serde test

[ChristianPavilonis]

Summary

• add a focused unit test for the invalid UTF-8 Cookie header path in handle_request_cookies
• rename the existing malformed-cookie test so it matches the behavior it actually covers
• remove a redundant callback serde rename test while preserving direct and broader deserialization coverage

Changes

File	Change
crates/trusted-server-core/src/cookies.rs	Renamed the malformed cookie-string test and added a new invalid UTF-8 cookie-header test using HeaderValue::from_bytes(...) to exercise the real InvalidHeaderValue branch.
crates/trusted-server-core/src/models.rs	Removed the duplicate callback serde rename test, keeping the existing focused direct test and broader callback deserialization coverage.

Closes

Closes #454
Closes #456

Test plan

• cargo test --workspace
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo fmt --all -- --check
• JS tests: cd crates/js/lib && npx vitest run
• JS format: cd crates/js/lib && npm run format
• Docs format: cd docs && npm run format
• WASM build: cargo build --package trusted-server-adapter-fastly --release --target wasm32-wasip1
• Manual testing via fastly compute serve
• Other: Rust-only test cleanup; no production behavior changes expected

Checklist

• Changes follow CLAUDE.md conventions
• No unwrap() in production code — use expect("should ...")
• Uses tracing macros (not println!)
• New code has tests
• No secrets or credentials committed

[aram356]

Summary

Test-only change closing real coverage gaps; CI is green and production behavior is unchanged. One blocking concern around a brittle assertion in the new UTF-8 test, plus two nitpicks.

Blocking

🔧 wrench

• Brittle assertion on error message text — cookies.rs:370 couples the test to the literal message string set in cookies.rs:108. Asserting on the variant alone (InvalidHeaderValue { .. }) is sufficient and survives reasonable message rewording.

Non-blocking

📝 note

• Issue #454 wording is stale — the "Done when" says invalid UTF-8 should return None, but handle_request_cookies actually returns Err(InvalidHeaderValue) (mapped to 400 Bad Request in error.rs:111). The PR test correctly exercises the real API; worth mentioning when closing #454 so the discrepancy is documented.

⛏ nitpick

• Explain why the bytes are invalid UTF-8 — \xF0\x90\x80 is a truncated 4-byte sequence; a one-line comment above the literal helps future readers.
• ts-ec=valid-prefix adds no coverage — to_str() validates the entire byte slice, so a bare b"\xF0\x90\x80" would exercise the same path more clearly.

CI Status

• fmt: PASS
• clippy: PASS
• rust tests: PASS (cookies::tests 25/25, models::tests 10/10 verified locally)
• js tests: PASS
• browser/integration tests: PASS

[aram356]

🔧 wrench — Brittle assertion: the if message.contains("invalid UTF-8") guard locks this test to the literal string set in cookies.rs:108 ("Cookie header contains invalid UTF-8"). A reasonable rewording of that message (e.g. "Cookie header is not valid UTF-8") would silently break this test even though behavior is unchanged. Production code branches on the variant, not the message — the variant check alone is sufficient.

Fix:

assert!(
    matches!(
        err.current_context(),
        TrustedServerError::InvalidHeaderValue { .. }
    ),
    "should return InvalidHeaderValue for non-UTF-8 cookie header"
);

[aram356]

⛏ nitpick — \xF0\x90\x80 is a truncated 4-byte UTF-8 sequence: \xF0 introduces a 4-byte code point but only two continuation bytes follow, so to_str() rejects it. A one-line comment above the literal would save future readers a trip to the Unicode tables.

// Truncated 4-byte UTF-8 sequence: `\xF0` starts a 4-byte code point but
// only two continuation bytes follow, so `to_str()` rejects it.
let invalid_cookie_value = HeaderValue::from_bytes(b"ts-ec=valid-prefix\xF0\x90\x80")

[aram356]

⛏ nitpick — The ts-ec=valid-prefix portion adds no coverage. HeaderValue::to_str() validates the entire byte slice; there is no partial parsing to test. A bare b"\xF0\x90\x80" would exercise the same code path more clearly. Harmless either way.