New signal (needs design pass): bulk environment/secret dump, gated on a nearby network sink

[squid-protocol]

Part of epic #1171.

🛑 Problem Statement

Beyond reading one specific known credential file (#1173's credential_targeting), some
info-stealers instead grab everything at once — serializing the entire environment-variable set
(JSON.stringify(process.env), os.environ copied/dumped wholesale) and shipping it out. In CI
pipelines especially, the environment often holds every secret the pipeline has access to, so this
is a stronger signal in principle than any single hardcoded or known-path secret.

This is flagged lower-confidence and needs its own design pass before implementation — unlike
the other sub-issues in #1171, "wholesale environment access" has real, common, legitimate uses
(debug logging, a health-check/status endpoint printing non-secret config, test harnesses). A bare
"reads all of process.env" match would likely be too noisy to ship on its own.

🎯 Objective

Work out whether a sufficiently narrow version of this signal exists — most likely gated the same
way #1173 proposes gating credential_targeting: only counted as a real signal when the bulk
env/config read is followed within a bounded line window by a network sink (sec_io), i.e. "grab
everything, then send it somewhere," not "grab everything" alone.

🛠️ Proposed Implementation

Open question, not a prescribed implementation — start by:

1. Checking how often bulk process.env/os.environ access already appears in the
   language-crucible corpus, and how often it's near an existing sec_io hit vs. not, to get a
   real base rate before writing any regex.
2. If the base rate suggests a viable narrow signal, follow New signal: credential/token-file targeting (what a worm is actually after) #1173's read+sink correlation pattern
   rather than inventing a new mechanism.
3. If it doesn't — explicitly close this as "not viable at acceptable precision" rather than
   shipping something noisy. That's a legitimate, documented outcome (see obfuscation_flag / GlassWorm-style detector: needs a real design decision, not a code fix #1150's own
   build-vs-deprecate framing).

✅ Acceptance Criteria

• Explicit decision recorded either way: a narrow, network-sink-gated signal shipped with
  tests and corpus verification, or a documented "not viable" close-out explaining why
• If shipped: false-positive guard tests specifically covering debug-logging and
  health-check-endpoint idioms
• If shipped: verified against the full language-crucible corpus before the golden-master
  rebless