Recover a service account's exact read access

Repair access.yaml. Preserve the single v1 ServiceAccount observability/collector. That authenticated account must get/list/watch every core Pod in checkout, get every core pods/log subresource there, and get/list/watch every apps Deployment there. Reads must include future object names and ordinary unrestricted collection requests. Grant no other resource action, no access outside checkout or at cluster scope, and no grant to any other principal. No Secret access or mutation is allowed. RBAC permissions add together; a narrow rule cannot revoke a broader grant. Core apiGroups is the empty string, pods/log is distinct from pods, and resourceNames restricts names rather than granting every future object. A RoleBinding resolves a Role in its own namespace or a cluster-scoped ClusterRole; a ClusterRoleBinding grants across namespaces. ServiceAccount subject namespace identifies the caller; when omitted in a RoleBinding it defaults to the binding namespace. Its full User identity is system:serviceaccount:observability:collector. Group subjects can authorize other members. Use a namespace Role or reusable ClusterRoles with scoped bindings. This simulation evaluates the supplied artifact's authorization attributes, including literal and wildcard future API groups/resources, with no pre-existing grants. It does not authenticate tokens, discover served APIs, apply admission/other authorizers, run aggregation, update immutable roleRefs or evaluate non-resource URLs. Every Group is assumed capable of containing another principal. Supported objects are ServiceAccount, Role, ClusterRole, RoleBinding and ClusterRoleBinding, with metadata, resource rules, resourceNames and subjects; rule resources support exact names, *, and */subresource. Inspect missing operations and concrete excess-grant witnesses, then repair without Reset.