404 telemetry: isSoftNav keys on sec-fetch-dest=empty, which any fetch() sets - scanner traffic confirmed misclassified as soft-nav (5 of 29 rows)

isSoftNav in not-found-capture.ts:61 is `secFetchDest === "empty"`. Any plain fetch() sets sec-fetch-dest: empty - it is not specific to a Next RSC navigation - so non-browser traffic is logged as a soft nav. CONFIRMED, not theoretical: 5 of the 29 softNav=true rows in the whole 404 corpus (2026-08-08 x2, 2026-08-09 x3) are a GraphQL-endpoint scanner - actorUserId NULL, single IP 34.97.130.89 across both dates, paths /graphql, /api/graphql, /v1/graphql, bursts 0.4-0.5s apart. Measured by db-pluto-cc 2026-08-22. Impact is on the DENOMINATOR, not on any live behaviour: the skew guard is dormant and skewSuspected has never fired, so nothing was mis-downgraded. But softNav is leg 1 of the 3-AND skew predicate and is quoted as a sample size - the honest count of real soft-nav 404s is 24, not 29, and any future nonzero reading inherits the same contamination. Fix direction (not settled): require a positive Next-navigation signal rather than the absence of a document dest - the RSC request header is the obvious candidate. Do NOT gate on nextUrlPresent: PLUTO-178 measured it FALSE on all 12 known-genuine soft-navs, so gating on it would drop every real one.