feat(credentials): narrow a namespace grant by secret name or label - #1859

A grant is the whole namespace. The provider holds `get` on every Secret and
the policy checks only the namespace, so granting an atespace the namespace its
model credentials sit in also grants it everything else there. That is a thin
line wherever actors and the control plane share a namespace -- installing
Substrate as a subchart of its consumer puts them together -- because the same
grant then reaches actor-id-ca-pool, and an actor holding the CA that signs
actor identities can mint any actor.

Add allowedSecretNames and secretSelector to a policy, so a grant can name the
credentials it means and nothing else, or label them and let the label carry
it. Both unset keeps the namespace-wide grant every existing policy already
means, so no policy has to change.

The criteria of one policy are AND-ed and the policies are OR-ed, as they are
in a Kubernetes RBAC rule. A policy carrying a namespace, a name and a selector
admits only a Secret in that namespace, with that name, carrying those labels;
to admit either, write a second policy. Each policy therefore keeps its own
grant: merging them would AND the selectors of separate policies together, and
would let a narrow policy take away the namespace a broad one granted.

secretSelector mirrors the shape of ateapi.Selector, so a policy selects
Secrets the way an ActorTemplate selects workers, and matchLabels is exact
equality as it is there. It is nested rather than a bare matchLabels: the
common grant narrows by label alone, where the only neighbouring field names
namespaces, and a bare matchLabels there reads as though it selected the
namespaces. The shape is mirrored rather than imported -- this is a config
file, not the API.

Namespace and name are settled before anything is read, so a Secret no policy
names is refused without a request to Kubernetes and cannot be probed for
existence. A grant narrowed by label needs the Secret in hand, and there the
refusal has to hide existence too: a Secret that is absent and one whose labels
do not match are refused with the same code and the same message, so a caller
cannot walk a list of names and learn what the namespace holds. A grant that is
not narrowed by label has already been admitted to every name there, so
NotFound tells it nothing new and is kept.

A malformed name or label would narrow a grant to nothing and read as the
policy being ignored, so loading rejects it rather than failing open later.

Signed-off-by: Jonathan Jamroga <[email protected]>

Keep only label-based narrowing (SecretSelector) for scoping which
Secrets an atespace grant may resolve. Per review feedback, name-based
narrowing (AllowedSecretNames) added unnecessary complexity; label
selection alone covers the intended use case.

Per review: replace the pre-fetch Decision enum with two plain methods
on NamespaceAuthorizer. authorize() now returns just (atespace, error)
before the Secret is fetched. AllowedUnconditionally reports whether
any grant for the atespace/namespace needs no label check, used only
to decide whether a missing Secret may be reported as NotFound.
AllowedSecret checks the fetched Secret against any matching grant,
including an unrestricted one. Existence is still hidden the same way
for grants narrowed by label.

Also switch namespace policy YAML parsing to yaml.UnmarshalStrict, so a
typo like matchLabel, or an unsupported field like matchExpressions,
fails to load instead of silently parsing as an empty selector that
grants every Secret in the namespace.