Cluster-wide, opt-in path-based routing (single shared host)

/area networking
/area API
/kind feature

Describe the feature

We'd like an opt-in, cluster-wide path-based routing mode for Knative
Serving. When an operator turns it on, every external-visibility Knative Service
becomes reachable at a single shared host under a templated path, e.g.:

https://apps.example.com/<namespace>/<name>/...

instead of its own external hostname (<name>.<ns>.<domain>). It's set once by
the operator and applies cluster-wide — no per-service or per-route config.
Cluster-local addressing is unchanged, and requests still land on the same
backend; only the external URL scheme changes.

We're actively prototyping this to test feasibility and want to drive it to
something landable — but we're opening this to get direction before committing
to a design (see "Approach" below).

Motivation

Today every ksvc gets its own external hostname, which assumes wildcard DNS and
per-host certs. Platforms hosting many small ksvcs behind a single ingress +
single cert currently fall back to net-istio-specific workarounds — a per-ksvc
VirtualService, a hand-maintained shared VirtualService, or a Lua
EnvoyFilter deriving the upstream authority from the first path segment. All
three live outside the Knative API and none keeps Route status in sync with how
the ksvc is actually reachable.

We'd like path-based addressing to be a first-class, ingress-implementation-
agnostic option driven by Knative itself.

How this differs from prior requests

This is not the per-route Dispatcher/path-map model from #11997 (where a
developer authors /search → svc-a, /login → svc-b). That model needs a new
CRD, ClusterDomainClaim collision handling, and the cross-namespace question
flagged as intentionally unsupported in KIngress.

Ours is the narrower, complementary case: swap the cluster's external
addressing scheme from per-host to per-path, set once by the operator. The two
could coexist.

Related: #11997 (per-route composition, open), #12588 (closed as question),
#15729 (Gateway API direction), #540 (original header/URI routing ask).

Approach (open — seeking direction)

We're keeping the implementation deliberately vague at this stage; the repo
where we're prototyping is a feasibility test and we expect to fine-tune later.
Our hope is this can be done without new CRDs or Route/Service API changes by
leaning on the path + host-rewrite semantics the ingress contract already
carries, but we haven't settled on the right mechanism and would value the WG's
steer on:

• where the switch + its parameters should live (feature flag + network config,
  a small new resource, …),
• how Route/Service .status.URL should reflect the path-based URL,
• how it should relate to the Gateway API direction (#15729) so it stays
  net-impl-agnostic and slots under a future HTTPRoute backend,
• known constraints to design around up front: cross-namespace exposure,
  shared-host TLS, and traffic tags.

Commitment

We're prototyping this now and intend to take it to completion — write up a
proposal, bring it to a Serving WG call, and do the implementation + any net-*
follow-ups. Looking for a thumbs-up on direction and guidance on the right shape
before we lock a design.

No files, tests, or entry points are named. Start with the Approach section and related issues #11997, #15729, and #540; the work is done when a design receives Serving WG direction and the implementation plus net-* follow-ups address configuration, status URLs, Gateway API compatibility, cross-namespace exposure, TLS, and traffic tags.