fix(scrapers): a single-colon ysm, bbs or yse PI key joins to nothing

[quntao-z]

Follows #2799, which taught the materializer to resolve a roster email alias to a real netid. A second shape of inferredPiUserKey still cannot join.

The gap

inferredPiUserKeyIdentity reads a person name out of dept:<unit>:<name> only. A single-colon namespace key, ysm:<name> or bbs:<name> or yse:<name>, falls through to the netid branch, where the payload is a name rather than a netid and is not an email alias either, so #2799's directory map does not reach it. The key joins to nothing and the entity stays lead-blocked.

Scale on Development

621 keys in those three namespaces, every one joinable to a user observation. On a 200-key sample the name resolver answers matched 161, ambiguous 22, absent 17.

missing_lead stands at 519 entities after #2799's data operation ran.

Excluded

nih-pi: keys are left unparsed on purpose. They name grant PIs who may hold no Yale appointment, and rows carrying them also raise grant_only_no_current_yale_source.

Pending application

This is a stored-data change, so merging the code moves nothing. It needs observations:materialize-pi-attributed-users --apply for the absent cases and then a re-materialization of the affected entities, because materializeCanonicalPiMemberships runs on the researchEntity path rather than the user path. This issue stays open until both passes have run on Development and missing_lead has been re-measured from the scoreboard.

[quntao-z]

Applied and verified on Development

Both passes ran, plus a gate re-run that turned out to be a required third step.

measure	before	after
missing_lead	515	336
role_assignments	13,866	14,049
student_ready	3,201	3,225
operator_review	1,064	1,039
mint errors per apply run	5	0
mint refusals	618	548

179 entities stopped being lead-blocked and 24 reached student_ready. The gap between those two numbers is not a shortfall: most of the unblocked rows still hold missing_card_description or thin_description, so a lead was necessary but not sufficient.

A third pass is required, and the report hides it

research-entity:rematerialize reported entitiesChanged: 4 for the 486 entities it visited, and it scoped its own re-gate to those 4. But 183 role assignments had been written, because the report compares tracked entity fields and a lead lives in role_assignments. Reading that report would have shown the operation as a near-total failure.

missing_lead moved by 4 until student-visibility:gate --apply ran over the corpus and re-decided 225 rows. So the sequence is three passes, not two:

1. observations:materialize-pi-attributed-users --apply --confirm-materialize-pi-attributed-users
2. research-entity:rematerialize --slugs=<lead-blocked entities carrying a PI attribution> --apply --confirm-rematerialize
3. student-visibility:gate --apply --confirm-student-visibility-apply --max-apply=<n>

Step 3 refuses without --max-apply, and refuses before writing anything, so an apply that omits it exits 1 having changed nothing.