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

*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.