[vnet] fix: forward proxy-port traffic to support web apps invisible to VNet

[nklaassen]

Fixes #63980

What this fixes

Fixes a VNet regression where web app access could break when a user assumes an access request in Web UI only (not in Connect), while VNet is already running. In that state, an FQDN may resolve to a cluster-backed "undecided" handler, and proxy-port traffic could be rejected instead of being forwarded to the proxy.

Root cause

For cluster-matched FQDNs handled by undecidedHandler, connection-time routing rejected non-SSH traffic unless the resolver returned a concrete web app match. When Connect-side app visibility didn't match apps that should be reachable from Web UI due to access requests, proxy-port traffic hit the reject path.

Change

In undecidedHandler:

• Keep existing permanent decisions for:
  • matched TCP app
  • matched web app
  • confirmed SSH target on :22
• Add cluster-match handling on web proxy port:
  • forward to web proxy via webAppHandler
  • cache this as a short-lived soft fallback (softWebHandler with TTL)
  • scope fallback to proxy-port traffic only

This avoids per-connection resolver calls during normal browser traffic, while still allowing periodic refresh in case the FQDN does not match a real web app and there is a matching TCP app that becomes visible later.

Why this is safe

• Does not change SSH behavior on :22
• Does not open other ports; non-SSH/non-proxy still rejects
• Keeps existing TCP app routing semantics

RFD alignment

This more closely matches RFD 0207’s connection-forwarding intent:

• proxy-port traffic for unresolved cluster-backed names should be proxied to web proxy
• non-22/non-proxy traffic should be rejected
• SSH remains handled on :22
  The TTL soft fallback is an implementation detail to reduce resolver churn, while preserving the same routing intent.

Tests

Added/updated TestPriority coverage in lib/vnet/vnet_test.go:

• cluster match on proxy port is reachable (regression case)
• cluster match still rejects non-SSH/non-proxy port (guard)
• proxy reachability validated via fake proxy sentinel response

Manual Test Plan

• Repro path (Web UI-only role): Start VNet in Connect, assume app access in Web UI only (not Connect), then open the cluster-subdomain web hostname on proxy port; confirm it is reachable.
• SSH guard: Using the same environment, verify SSH to a valid node on :22 still works as expected.
• Port guard: Attempt a dial to the same hostname on a non-proxy, non-22 port (e.g. :12345); confirm it is rejected.
• Soft-cache sanity: Hit the same web hostname multiple times quickly for >15s; confirm behavior stays stable (no intermittent reject).
• Connect parity control: Assume the same access request in Connect and retry; confirm access still works (no regression when Connect-side visibility is present).

Changelog: Fixed a VNet regression where web app access could fail when access was assumed in the Web UI only while VNet was already running

[nklaassen]

cc @ravicious if you want to see this one, it solves a very similar problem as my previous vnet web app access fix, except this one solves it in cases where VNet cannot query the web app at all