Document trusted-server.example.toml and restore supported config sections

[aram356]

Closes #869. Closes #871.

Two related commits on the config surface.

1. Document trusted-server.example.toml and restore supported sections

Reworks the app-config template (source-controlled starter, also embedded into the Cloudflare/Spin adapters via include_str! and text-patched by ts audit).

• Required minimum stays active + documented: [[handlers]] (admin), [publisher], [ec].
• Every optional section/integration is commented out with a one-line description.
• Restores dropped-but-still-supported sections: [tester_cookie], [rewrite], [consent], [image_optimizer], [tinybird], [integrations.osano], publisher.max_buffered_body_bytes, sourcepoint.auth_cookie_name, DataDome protection fields, Prebid override rules.
• Keeps gpt/didomi/datadome/google_tag_manager as active enabled = false stubs so ts audit can flip them in place. All hosts are example.com.

2. Reject fail-open placeholder config values at deploy validation

ts config validate/push route through TrustedServerAppConfig::validate → validate_settings_for_deploy. That path now rejects template placeholders that previously validated OK and only failed at runtime:

• publisher.domain / cookie_domain / origin_url left at the example.com template defaults.
• request_signing.config_store_id / secret_store_id when the block is enabled (empty or <management-...> placeholders).
• integrations.aps.pub_id when APS is enabled — non-empty via the built-in length(min = 1) validator, plus a custom validator for the reserved your-aps-publisher-id placeholder.

Why some checks use the validator crate and some don't

• APS leans into the validator crate: integration configs validate lazily through get_typed (enabled-gated), so #[validate(length(min = 1), custom(...))] fires only when APS is on.
• Publisher / request_signing stay in the deploy-only reject_placeholder_secrets: Publisher::validate() runs at parse time on the embedded example.com template (a #[validate] rule would reject the template itself), and request_signing rejection must be gated on the sibling enabled flag — neither is expressible as a single-field attribute. This mirrors how the existing placeholder-secret rejection already works.

Verification

• cargo test -p trusted-server-core --lib — 1628 pass (incl. 4 new deploy-validation tests + an enabled-gating test).
• cargo test --package trusted-server-cli ... audit — pass.
• Settings::from_toml on the template — pass (deploy rejection is separate from parse).
• cargo clippy -p trusted-server-core --lib with -D warnings — clean.

Follow-up (not in this PR)

A validator-usage audit across all config structs found two pre-existing hand-rolled validators that reimplement a built-in — GTM validate_container_id and Prebid validate_external_bundle_sha256 could become #[validate(regex(...))]. Deferred: #[validate(regex)] is used nowhere in the repo yet (validator pulled with only the derive feature), so swapping pre-existing code carries compile/behavior risk best handled on its own.