Refuse the team agnostic fall-through for a team scoped Lockbox secret name

[potiuk]

The team scoped lookup runs first and, on a miss, falls through to the team
agnostic name. A guard was meant to stop a caller naming another team's secret:

return team_name is None and bool(re.fullmatch(..., secret_id))

Its first condition is team_name is None, so it does nothing whenever a team
scope is supplied — exactly when it matters. A caller authorised for one team
could supply an id spelling out another team's namespace; the team scoped probe
missed, and the team agnostic lookup resolved the other team's secret.

Approach

1. the team scoped lookup runs first — safe by construction, since it can only
   ever build the caller's own namespace;
2. after it misses, an id that spells out any team namespace is refused rather
   than resolved through the team agnostic name;
3. otherwise the team agnostic lookup proceeds as before.

The id is never parsed to work out which team it names, because it cannot be:
a team name may itself contain the separator, so nothing in the string
distinguishes one team's namespace from another whose name extends it. Comparing
the id against the prefix the caller's own team builds looks equivalent and is
not — a caller in team a matches a--b's namespace on the prefix and would read
its secrets. Only the caller's own namespace is ever constructed, never parsed.

Behaviour change

An id that spells out a team scoped name is no longer resolvable through the team
agnostic name from any scope, including the team that owns it — that spelling is
what made a prefix match look like ownership. Callers reach their own team's
secrets with the bare id plus their team scope, which is unaffected, as are
single-team and non-team deployments.

Test plan

• New tests: a caller scoped to one team cannot reach another team's secret by
  naming it, and a team whose name extends the caller's (teama--prod vs
  teama) is not reachable either
• Both new tests fail against the unmodified backend — the target secret is
  resolvable in the fixture, so a backend that falls through returns its value
• Existing team-scope tests unchanged and passing
• ruff check / ruff format clean

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 5 (1M context)

Generated-by: Claude Opus 5 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions