pr-labeler: a title scoped constructor or toString kills the label job through a bare prototype lookup #4125

.github/workflows/pr-labeler.yaml looks both of its tables up bare: typeToKind[type] at line 192 and scopeToArea[s] at line 205. Neither table has a null prototype, so a key inherited from Object.prototype resolves to a function instead of to nothing. A function is truthy, so it gets added to the label set, and the [...toAdd].some(l => l.startsWith('area/')) at line 218 then throws l.startsWith is not a function and the step dies.

Reproduced with the same lookup shape and the same consumer:

vm-instance      string   -> area found
constructor      function -> THROWS: l.startsWith is not a function
toString         function -> THROWS: l.startsWith is not a function
hasOwnProperty   function -> THROWS: l.startsWith is not a function

Both entry points are reachable from a title. The scope is captured by ([^)]+) or [^\]]+, so constructor, toString, hasOwnProperty and __proto__ all pass through it. The type is constrained to ^([a-z]+), which still admits constructor, so a title of constructor: anything reaches it on its own.

Sizing it rather than escalating it: the workflow triggers on pull_request_target, so the title is attacker-controlled from a fork, but the consequence is a dead labeling step. No code runs and no token is exposed. What it costs is that the pull request gets no labels at all, and the failure is quiet in the same way as #4124, because nobody goes looking at a labeler that did not label.

Object.hasOwn(scopeToArea, s) and Object.hasOwn(typeToKind, type) close both sites. This belongs next to the double-backport bug: same class, a title parsed into a lookup that silently yields something other than a mapping, and both would be caught by the contract test this workflow does not have.