A durable tool/call naming itself `__proto__` reached bumpToolTotals, whose
Object.hasOwn guard passes for it — the key is never an own property. The
plain assignment then set the tally's prototype instead of booking a row:
the count was lost, the 16-name cap never saw the key, and foldWire's
`for...in` copied the inherited `calls`/`ms` as `{}`, which the strict
tool-timing schema rejects. The registry parses every served view with no
error boundary, so that throw stalls the unit's push feed — the "loading"
forever failure compatibility.md designs out, and the same defect the
compat matrix already pins as `poisonedStarves`.
The client boundary has skipped this name since issue #44, with a
regression test beside it; the host fold, where the untrusted name first
lands, did not. The hostile fixture needs no second tool run to reproduce:
a later one re-clones the tally through a spread, which launders the damage.
bowenliang123
3611d50419