[Feature]: Configurable traffic-log sinks — write traffic logs to a file or push them to a log platform instead of stdout

Please select the area the issue is related to

Gateway

Please select the aspect the issue is related to

Aspect/Logging (Log formats, instrumentation, improvements), Aspect/Configuration (Config files, settings, env vars, defaults), Aspect/Monitoring (Metrics, observability, health checks, alerts)

Suggested Feature

The traffic log is the only thing the gateway emits that deliberately carries request and
response bodies, and today it has exactly one destination, hard-coded:

// gateway-runtime/policy-engine/internal/analytics/publishers/log.go
out *os.File
...
out: os.Stdout,

Everything unwelcome follows from that single field:

• Bodies land in the container log, so the kubelet writes them to /var/log/pods/… on the node.
• Anyone with kubectl logs on the namespace can read unredacted PII.
• Any node-level log collector already running — a DaemonSet agent, a Splunk Universal
  Forwarder on the host — picks them up and ships them onward automatically, with no
  configuration. On a cluster that already forwards container logs to a SIEM, enabling
  [traffic_logging] silently starts sending request bodies to a long-retention,
  org-wide-searchable index.
• Reading the log requires something co-located (a sidecar, or a DaemonSet with hostPath).
  Several customers are not permitted to run either.
• The line is wrapped by the entrypoint's [pol] stdout prefix, which forces a fragile
  strip-the-prefix parser downstream. A JSON parse failure there previously let an
  unredacted line through to a log store.

This is structural to the stdout path — no downstream configuration fixes it, because the
unredacted copy already exists on disk by the time anything else sees it.

Related Issues

No response

Steps to Verify

• Design Document — A detailed design document has been created and reviewed, covering architecture, data flow, and edge cases.
• Design Mail — A design summary email has been sent to relevant stakeholders for awareness and feedback.
• Code Review — All code changes have been peer-reviewed and approved according to the project's review standards.
• Testing Complete — Adequate unit, integration, and/or end-to-end tests have been written and are passing.
• Documentation Review — User-facing and/or developer documentation has been updated to reflect the new feature and reviewed.
• Feature Complete — The feature is fully implemented, all checklist items above are done, and it is ready for release.