Venus PTD cannot bind a SHA to a deployment: no githubCommitSha in either vercel inspect form

Raised by pmmaster ms7lfb518cks after coder-venus-cc stated it as a coverage limit on the c31ae83 PTD (ms7lemwnjjry): 'a real gap in the PTD instrument, not a defect in this push — worth raising as its own item since it affects EVERY venus PTD.' MEASURED: neither 'vercel inspect' form returned a githubCommitSha field. So on venus the SHA-to-deployment binding is VERSION-MATCH PLUS CREATION TIMESTAMP, not a direct commit read. Both halves of the current evidence are indirect: /api/health returns {version, deploymentId} and vercel inspect returns Ready/target/aliases, but nothing in that chain asserts WHICH COMMIT produced the deployment. WHY IT MATTERS: PTD's whole purpose is catching a silent frozen prod — a deploy that reads READY while the alias serves older code. Version-match catches the common case only because package.json is bumped every push; it cannot distinguish two pushes at the same version, a re-deploy of an older commit at a matching version, or a build from a different ref. The instrument answers 'is a deployment at this version live' and is being read as 'is this commit live'. Deliverable is a read path that binds commit -> deployment, or an explicit statement that none exists on this account tier plus the strongest available substitute stated as such in every venus PTD. Do not close it by asserting the current evidence is sufficient without measuring the alternatives (Vercel REST deployments API, deployment meta fields, exposing the SHA from the app itself via a build-time env var into /api/health). Not urgent, not under the rail freeze. Affects every venus PTD going forward.