tunnel: prioritize Tunnelstore lookup over configured credentials file in findID

[dedsec-terminal]

Problem

When a tunnel name is provided to commands such as cloudflared tunnel route dns <name> <hostname>, sc.findID returned the TunnelID from any configured credentials file (e.g. credentials-file specified in config.yml or via --credentials-file) before querying Tunnelstore. Because credentials files do not contain tunnel names, findID could not verify whether the file matched the requested name, leading to routes or operations silently applying to an unrelated tunnel.

Change

1. In findID, query Tunnelstore (sc.tunnelActive(input)) first when input is not a UUID. If the tunnel is found by name in Tunnelstore, return its ID directly.
2. If Tunnelstore cannot be queried (for example, running in credentials-file-only environments without an origin certificate), fall back to looking up the ID in the configured credentials file.
3. Added unit tests in Test_subcommandContext_findID verifying:
   • Direct parsing of UUID input without Tunnelstore or credentials lookup.
   • Tunnel name resolving via Tunnelstore even when an unrelated credentials file is configured.
   • Non-existent tunnel name returning not found without falling back to the configured credentials file.
   • Fallback to credentials file when Tunnelstore is unavailable.
   • Error handling when Tunnelstore is unavailable and credentials file is missing.

---

Fixes #1762

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[jtannahill]

Thanks for picking this up. I tested 225e404 against the setup I reported in #1762 (macOS arm64, Go build of this branch vs. master). ~/.cloudflared/config.yml names tunnel humanizer (9bd479cb...) via tunnel: and credentials-file:, and I used the read-only tunnel info, which goes through the same findID path as route dns:

Command	master	this PR
tunnel info lionsailing-staging	resolves to humanizer / 9bd479cb... (the bug)	resolves to lionsailing-staging / df9ff5bb...
tunnel info <UUID>	correct	correct
tunnel info no-such-tunnel-xyz	(returns the config's tunnel)	is neither the ID nor the name of any of your tunnels
--origincert /nonexistent/cert.pem tunnel info lionsailing-staging	n/a	Error locating origin cert, no misroute

go test ./cmd/cloudflared/tunnel/ passes, including the five new findID cases.

One suggestion: the fallback to the credentials file runs on any error from tunnelActive, not only when there is no origin cert. So with a cert present, a transient Tunnelstore failure (timeout, 5xx, rate limit) would still return the credentials file's tunnel without checking it against the name, which is the original misroute, just less often. It might be safer to fall back only when no API credential is available (e.g. sc.credential() fails) and return the Tunnelstore error otherwise, or at least log a warning naming the tunnel ID it fell back to.

[jtannahill]

Retested 7b86969 with the same setup: go test ./cmd/cloudflared/tunnel/ passes (all 6 findID cases). With a cert, tunnel info lionsailing-staging resolves to df9ff5bb... and an unknown name errors out. With --origincert /nonexistent/cert.pem, it logs the fallback warning naming 9bd479cb... and nothing gets misrouted. This addresses my concern, thanks. LGTM from the reporter side.