Implement or reject Tinybird telemetry configuration coherently #1148

Context

Tinybird auction telemetry is implemented by the Fastly adapter; the other adapters currently use the core no-op sink. TinybirdSettings accepts auction telemetry settings but rejects tinybird.access_enabled = true during normalization because no access-log emitter is wired. docs/guide/telemetry.md now describes both limits, so the PR #1049 finding is no longer an undocumented contradiction. The remaining question is the intended support matrix and whether to implement or retire the reserved access-log configuration.

Desired outcome

A deliberate, consistent telemetry contract across configuration validation, runtime emission, and adapter documentation. Operators should not infer that an accepted setting produces telemetry on an adapter with no sink.

Scoped work

• Decide which telemetry types and adapters are supported now. For access-log settings, either implement an emitter with a supported contract or retire or continue explicitly reserving the fields with clear validation.
• Decide how auction telemetry configuration behaves on adapters without a sink: reject, warn, or document an intentional no-op. Align parser and runtime behavior with that decision.
• Update the Tinybird and telemetry guides and add adapter-specific tests for enabled, disabled, and unsupported combinations.

Done when

• A support matrix identifies auction and access telemetry behavior for each adapter.
• Tests verify the documented behavior for tinybird.enabled and tinybird.access_enabled on supported and unsupported adapters.
• No accepted configuration silently promises an event stream that the selected contract does not provide.
• Configuration, telemetry, and adapter guides match the implementation.

Evidence

Original PR #1049 documentation finding; current crates/trusted-server-core/src/settings.rs, crates/trusted-server-adapter-fastly/src/tinybird.rs, and docs/guide/telemetry.md at 666953a0d.