Trials P-35, P-36, P-37 and P-38: what a Lens's check is read from, the queue's base, and the approved commit #186

Part of the epic "Epic: slice 1, first approval. A Release on next reviews a pull request to this repo, and the machine user's approval stands".

Why. Batch 2 of §6.1. The Kernel reads a required Lens only from its own App and workflow path (decisions 0022, 0026), reads what a Lens judges from the base its merge-queue group is built on (0023), and reads an approved contract at its commit (0025). Each rests on a platform fact nobody has read; three rows of those records say so.

Done when

• P-35: each check run's workflow path is readable in the one read of the facts, with the reader's and the Controller's permissions; whether it ever carries a ref suffix or a dynamic/ form; where a check created with GITHUB_TOKEN and checks: write lands, and that it cannot update another workflow's check; that a job a pull request adds under a required Lens's name reports with its own file's path; whether CodeQL's check has a workflow run.
• P-36: an upload to code scanning under CodeQL's tool and category by an identity with security_events: write cannot change the CodeQL check's conclusion. If it can, tools/check_workflows.py's refusal of security-events: write is the rule, and the fixture says so.
• P-37: for a merge-queue entry behind another, merge_group.base_sha is the head of the group ahead and the parent of the entry's own head, every time.
• P-38, only if Trials P-1 and P-7: an App's pull request, approved by the machine user #14's sitting did not record it: a review dismissed as stale stays readable with its commit and reviewer, and the timeline names who dismissed it.
• Each fixture grounds its rule in sim/grounding.py.

Needs. The canary's merge queue from batch 2a. No machine-user token except for P-38.

Design. §6, P-35 to P-38; §4.9; decisions 0022, 0023, 0025, 0026.