vhds: support fully on-demand (non-wildcard) initial subscription

[bruce-zzz-135]

Title: vhds: support fully on-demand (non-wildcard) initial subscription

Description:
Today, every VHDS (Virtual Host Discovery Service) subscription unconditionally starts as a
full wildcard fetch: the first delta-xDS request Envoy sends for the VirtualHost resource
type has an empty resource_names_subscribe, which per delta-xDS convention means "send me
everything." The management server pushes every virtual host for the route configuration up
front; on-demand lookups (via the on_demand HTTP filter, triggered on a route-lookup miss)
only ever add to that initial full fetch — they never replace it.

This defeats a common motivation for using VHDS: large virtual-host counts where the goal is to
avoid ever pushing hosts nobody has requested. There is currently no way to configure VHDS to
skip the initial wildcard fetch and rely purely on on-demand lookups from the start.

Root cause, briefly: VhdsSubscription sets SubscriptionOptions::use_namespace_matching_ = true (the only subscription type that does), and the generic delta-xDS mux layer
(NewGrpcMuxImpl::updateWatch / xds_mux::GrpcMuxImpl::updateWatch) unconditionally discards
any resource-interest updates for namespace-matching subscriptions to avoid leaking
prefix-like names onto the wire — as a structural side effect, this also permanently keeps the
underlying DeltaSubscriptionState in "legacy wildcard" mode, regardless of what resource
names VHDS actually wants.

Proposed solution

• Add an InitialFetchType enum (WILDCARD default / ON_DEMAND) to the
  envoy.config.route.v3.Vhds proto, so operators can opt a given VHDS-enabled route
  configuration into starting with zero subscribed virtual hosts.
• Add an orthogonal SubscriptionOptions flag so the mux layer can distinguish "use namespace
  matching for local alias dispatch" (needed in both modes) from "assume wildcard interest by
  default" (only for the legacy/default mode), and thread a matching "start non-wildcard"
  knob into DeltaSubscriptionState's construction, since simply passing an empty resource set
  isn't sufficient — the state machine currently defaults to treating an empty initial
  interest set as wildcard-by-convention.
• Gate behind a envoy.reloadable_features.* guard in addition to the explicit
  proto opt-in.
• Out of scope for a first iteration: eviction of on-demand-added virtual hosts (VHDS has no
  removal path today, wildcard or not), and mixing WILDCARD/ON_DEMAND VHDS route configs
  that share a single ADS transport (they'd currently share one DeltaSubscriptionState, so
  this would be documented as unsupported rather than solved in v1).

Filing this for early feedback on approach/API shape before putting up a PR. Happy to expand
with exact file/line pointers on request.