fix(proxy): stop allow_domain endpoint route from shadowing credential catch-all

[panga]

Linked Issue

Closes #1131

Summary

Fixes a route-selection bug where a credential catch-all (custom_credentials
with no endpoint_rules) was shadowed by a credential-less _ep_ endpoint-authorization
route (from an allow_domain entry with endpoints) on the same upstream. On a path the
_ep_ route authorized, the proxy selected the credential-less _ep_ match ahead of the
catch-all and forwarded the request without injecting the managed credential.

The fix changes the selection priority so a credential-bearing catch-all wins over a
credential-less _ep_ match on authorized paths. Selection priority is now:

1. a matched route carrying a managed credential;
2. a credential-bearing catch-all (the new step — prevents the shadowing);
3. any other match (bare endpoint authorization);
4. the catch-all (un-credentialed passthrough).

As part of the fix, the route-selection logic (the _ep_ hard-deny gate, the ambiguity
check, and the priority ordering) was extracted from tls_intercept/handle.rs into a single
select_route function + RouteSelection enum in route.rs. This gives the decision one
source of truth shared with its unit tests — the previous test was a hand-copied mirror that
didn't even model the _ep_ gate, so it could not have caught this bug.

What is intentionally unchanged

• _ep_ routes are kept. They enforce auth-less default-deny on paths; removing or merging
  them would let paths the credential's endpoint_rules don't match through un-credentialed.
• The endpoint hard-deny gate (has_endpoint_only_route && !endpoint_authorized → 403) and
  the ambiguity check (multiple credential routes → 403) are byte-for-byte equivalent to the
  prior behavior, including the audit denial_category, reason strings, and HTTP status codes.
• The host gate is untouched: a custom_credentials-only host that is not in allow_domain
  stays denied at the host filter.

Agent Disclosure

• This PR was generated by an AI agent (Claude Code).

Test Plan

• Added test_route_selection_credential_catchall_not_shadowed in route.rs:
  • authorized path (GET /org/repo) → credential catch-all selected (token injected) — this
    fails on the old ordering and passes after the fix;
  • non-matching path (GET /other/repo) → EndpointDenied (default-deny preserved).
• Updated test_route_selection_multi_org_profile to exercise the real select_route via a thin
  test adapter instead of a hand-copied mirror.

Manual repro: profile with github.com in allow_domain (org-scoped endpoints) + a
custom_credentials github_api catch-all → authorized path now injects the token; a
non-authorized path is still 403.

Checklist

• An issue exists and is linked above
• All commits are signed-off, using DCO
• All new code follows the project's coding standards (CLAUDE.md) and is covered by tests
• Public-facing changes are paired with documentation updates
• Release note has been added to CHANGELOG.md if needed

Agent Compliance Check

• I am not prohibited from contributing under this policy
• An issue already exists
• I disclosed that I am an agent in the issue discussion
• I described my intent and approach in the issue discussion
• I reviewed repository coding and security rules for the affected area
• I provided required attribution for reused or adapted code
• I did not use forbidden patterns such as unwrap/expect
• I used NonoError where required
• I validated and canonicalized all relevant paths
• This PR matches the approved or disclosed issue scope

[github-actions]

PR Review Summary

Size

Metric	Value
Lines added	+246
Lines removed	-119
Total changed	365
Classification	Large (> 300 lines)

Affected crates

• crates/nono-proxy — downstream consumers depend on this crate. API or behaviour changes will affect external callers; treat any breaking change with extra scrutiny.

Blast radius — Contained

This PR touches: source code

---

_{Updated automatically on each push to this PR.}

[gemini-code-assist]

Code Review

This pull request refactors the route selection logic out of tls_intercept/handle.rs into a dedicated select_route function in route.rs, introducing a RouteSelection enum and adding corresponding unit tests. Feedback on the changes identifies a latent shadowing bug in select_route when multiple catch-all routes exist, where a credential-bearing catch-all could be shadowed by a credential-less catch-all, or ambiguity between multiple credential-bearing catch-alls could be silently ignored. A refactored implementation is suggested to properly classify candidates and resolve these edge cases.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[SequeI]

Left a small question about the logic for matched_creds, let me know if I am off base there. After that is resolved, we can get this merged :)

[SequeI]

This runs before we ever check matched_creds so it does not matter that a credential route already matched, we still bail out early. credential route match is invisible to this check

[panga]

You're right that the gate runs before we look at matched_cred, and that a matched credential route doesn't flip endpoint_authorized. That's intentional, and it's also the pre-refactor behavior.

The reasoning: an ep route (from an allow_domain entry with endpoints) is a network-level default-deny gate, not a per-credential concern. When such a route exists for the upstream, the request must match the host's allowed endpoint surface before we get to choose/inject a credential. A credential route matching the path authorizes credential injection on that path, but it does not by itself widen the host's endpoint allow-list — otherwise a custom_credentials catch-all could grant access to paths the operator deliberately scoped out via allow_domain endpoints, which is exactly the bypass this gate exists to prevent.

So the ordering is deliberate: gate on the host's endpoint policy first (credential match is intentionally invisible here), then select among credential routes.

[SequeI]

lgtm, thanks!