Add DataDome server-side protection

[ChristianPavilonis]

Summary

• Adds DataDome server-side Protection API validation before route matching, with fail-open behavior and challenge short-circuiting.
• Adds request-filter infrastructure for integrations to mutate upstream request headers and final response headers.
• Moves the DataDome server-side key to runtime Secret Store configuration and documents staging/deployment behavior.

Changes

File	Change
crates/trusted-server-core/src/integrations/registry.rs	Adds integration request-filter traits, decisions, header effects, mutation semantics, and registry execution.
crates/trusted-server-core/src/integrations/datadome.rs	Adds DataDome protection config, Secret Store key references, auto-injection, and request-filter registration.
crates/trusted-server-core/src/integrations/datadome/protection.rs	Implements protection matching, payload construction, Secret Store key loading/cache, Protection API calls, response classification, and pointer-header extraction.
crates/trusted-server-adapter-fastly/src/main.rs	Runs request filters after basic auth and before route matching; applies response effects after finalization.
crates/trusted-server-adapter-fastly/src/platform.rs / crates/trusted-server-core/src/platform/types.rs	Extends client metadata with JA4/H2 fingerprint and edge server metadata.
crates/trusted-server-adapter-fastly/src/route_tests.rs	Adds route-level coverage for DataDome protection behavior.
crates/trusted-server-core/src/platform/test_support.rs / src/http_util.rs	Updates test support/default client metadata helpers.
crates/trusted-server-core/Cargo.toml	Adds dependencies needed by the DataDome protection implementation.
trusted-server.toml	Documents new DataDome protection, Secret Store, and auto-injection settings.
docs/guide/integrations/datadome.md	Documents first-party proxy, server-side protection, fail-open behavior, headers, Secret Store config, and GraphQL v1 limitation.
docs/superpowers/specs/2026-06-11-datadome-server-side-protection-design.md	Adds and updates the implementation spec/status for the DataDome server-side protection work.

Closes

Closes #317

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: cd docs && npx prettier --check guide/integrations/datadome.md superpowers/specs/2026-06-11-datadome-server-side-protection-design.md

Checklist

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

[aram356]

Summary

Adds DataDome server-side Protection API validation plus generic integration request-filter infrastructure. The implementation is solid: response effects are applied on every HandlerOutcome path, integration config is validated at load time, fail-open is deliberate and tested, and the new filter infra is cleanly factored and unit-tested. All 14 CI checks pass, and I separately verified the wasm32-wasip1 release build (which CI does not gate) compiles. Approving — every finding below is non-blocking.

Non-blocking

🤔 thinking / 🌱 seedling / 📝 note

• Config/setup errors fail open silently — see inline at crates/trusted-server-core/src/integrations/datadome/protection.rs:51
• Head-injector attribute-context escaping — see inline at crates/trusted-server-core/src/integrations/datadome.rs:736
• Server-side key cache has no TTL — see inline at crates/trusted-server-core/src/integrations/datadome/protection.rs:37
• Challenge response depends on the pointer header — see inline at crates/trusted-server-core/src/integrations/datadome/protection.rs:406

Cross-cutting / body-level findings

• 🤔 Test coverage gap — Behavioral tests cover the 403 challenge and 200 allow paths well, but not the 301/302 redirect-challenge path nor x-datadome-request-headers upstream enrichment routed through a real classify_protection_response result. Adding both would close the gap and lock in the redirect/Location behavior.
• 📌 No wasm32-wasip1 build gate in CI — This PR adds wasm-sensitive runtime dependencies (chrono::Utc::now(), std::time::Instant, std::env::var, urlencoding) on the request hot path. I verified the wasm32-wasip1 release build compiles locally, but nothing in CI guards it. Worth a follow-up issue to add a wasm build job. (Out of scope for this PR.)

CI Status

• cargo fmt: PASS (required)
• cargo test: PASS (required)
• format-typescript: PASS (required)
• format-docs: PASS (required)
• vitest: PASS
• CodeQL: PASS
• Analyze (rust): PASS
• Analyze (javascript-typescript): PASS
• Analyze (actions): PASS
• integration tests: PASS
• browser integration tests: PASS
• prepare integration artifacts: PASS