Correct OTLP metrics/logs behaviour to 404, and start Phase 2

Alloy only registers an OTLP/HTTP route for a signal with an output, so
POST /v1/metrics and /v1/logs return 404 rather than being accepted and
silently dropped (verified live against otlp.vione.cloud). Fix the claim
everywhere it appeared. Also mark Phase 2 in progress.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

k8s/README.md

@@ -43,7 +43,8 @@ OTLP/gRPC (4317) is cluster-internal only. Apps use OTLP/HTTP.
   empty in the role too; see `prometheus/prometheus.yml`).
 
 The CLAUDE.md platform facts still hold:
-- OTLP metrics and logs are silently dropped.
+- OTLP metrics and logs are rejected: Alloy returns a 404 on `/v1/metrics` and
+  `/v1/logs`, so the only sign is an export error in the app's own logs.
 - Span metrics and the service graph come from Tempo's metrics-generator.
 - The Loki derived field matches lowercase `trace_id`.
 - Datasources are provisioned; dashboards are not.

k8s/alloy/config.alloy

@@ -7,7 +7,8 @@
 // observability/alloy-agent/config.alloy.
 //
 // What remains is unchanged: the OTLP receiver wires a `traces` output and
-// nothing else. OTLP metrics and logs are accepted and silently dropped.
+// nothing else. The HTTP server only registers routes for signals with an
+// output, so OTLP/HTTP POSTs to /v1/metrics and /v1/logs get a 404.
 
 logging {
   level = "info"