/debug/queue endpoint is always on and leaks names across namespaces

[chmouel]

📝 Description

#2890 added a /debug/queue endpoint to the watcher that lists, for every
namespace, the Repository names, their concurrency limits, and the names of
running and pending PipelineRuns.

The PR description says the endpoint is off unless explicitly switched on.
The code does not match: cmd/pipelines-as-code-watcher/main.go:36 registers
the handler unconditionally, with no flag, no environment variable and no
authentication. It listens on the probe port (8080), which is declared as a
container port and reachable at the pod IP from anywhere in the cluster.
The Service only publishes 9090, but that does not block direct pod
connections, and the project ships no NetworkPolicy.

The comment in pkg/queue/debug.go argues callers could already list these
names through the Kubernetes API. For PipelineRun pods that is usually false:
they commonly run with no API permissions at all, yet they can open network
connections. Pipelines-as-Code exists to run code from pull requests, so
untrusted code running curl <watcher-ip>:8080/debug/queue gets a cluster-wide
inventory of repository and PipelineRun names it could not otherwise see.

🛠️ Suggested fix

Register the route only when an explicit setting enables it, for example an
environment variable PAC_ENABLE_QUEUE_DEBUG parsed with strconv.ParseBool,
default off, failing closed on an invalid value. Leaving the route absent is
better than answering 403.

Two things depend on the endpoint today and need to opt in:

• the E2E helper QueueSnapshot (test/pkg/kubestuff/watcher.go:100)
• the documentation at docs/content/docs/advanced/concurrency.md, which
  currently shows a plain curl with no enablement step

🧪 Testing Strategy

• Unit tests: route absent when disabled, present when enabled
• End-to-end tests: E2E install sets the variable so QueueSnapshot keeps working