404 telemetry anomaly: 7-row burst is nextUrlPresent=TRUE with clientBuildId=NULL - the exact inverse of the 12-row confirmation set, unexplained

Two 404-telemetry signals disagree on exactly one population and nobody can currently explain it. Corpus-wide (10518 page_not_found rows), nextUrlPresent=TRUE appears on exactly 7 rows: one 6-minute burst, 2026-07-17 05:39-05:45 UTC, one authenticated user (98b5383b-ff4b-4b1e-a16a-ac9d5d38508d), real browser UA, single IP 181.44.116.128, paths /administrar/comisiones/<uuid>, a different uuid each time. All 7 also have clientBuildId NULL. That is the inverse of the confirmation set: all 12 rows with a NON-null clientBuildId (genuine bundle traffic by construction) have nextUrlPresent=FALSE. So the two signals agree everywhere except here, where both flip at once. The open question is which model is right, and they give opposite readings of the same 7 rows: (a) next-url is stripped by the Vercel edge on EXTERNAL requests (the not-found-log.ts:60-64 claim, now confirmed n=12). Under this model TRUE means the request did NOT arrive as a normal external browser nav, and the burst is something other than what its UA says. (b) next-url populates on a genuine RSC soft-nav and our 12-row set is FALSE for an unrelated reason. Under this model the burst is the ONLY confirmed real soft-nav that lost its x-deployment-id, i.e. a genuine plumbing gap in the skew instrument. Do not resolve this by argument - it needs a probe. Server-side appEvents cannot separate the models; db-pluto-cc reached the same limit independently 2026-08-22. Related but NOT the same as PLUTO-725 (scanner rows there are actorUserId NULL with scanner paths; this burst is authenticated with real app paths). Blocks nothing: the 0/0/0 skew baseline holds under either model.