Add reusable stack-health harness and one-switch privacy mode for agent-pack auditing

[opencoca]

This PR adds a config-driven Health Harness for auditing agent packs (skill packs,
prompt packs, tool bundles, browser automation) against three categories of risk:

• Integrity Regressions — generated file staleness, touchfile drift, audit invariants
• Privacy/Egress Surfaces — outbound telemetry, remote update checks, hosted dashboard calls
• Manipulation-Pattern Policy — founder funneling, authority conversion, mania-adjacent
  hype, coercive urgency, dependency-building copy

It also introduces a one-switch network_egress off mode that hard-disables all
hosted egress paths while preserving local-only analytics and local health checks.

---

Why a harness (not just one-off grep)

Agent packs are prompt-heavy, generation-heavy codebases where:

1. Dark patterns compound silently. A preamble resolver injects persuasion copy
   into every generated SKILL.md. A single manipulation pattern in a shared template
   propagates to dozens of skills. Grep catches one instance; the harness catches the
   propagation rule.

2. Integrity checks are already scattered. Freshness checks, touchfile consistency,
   and audit dry-runs exist but run in separate test tiers. The harness unifies them
   under one bun run stack:health entry point with --json, --strict-warnings,
   and --only <check-id> filtering.

3. Policy debt needs a ratchet, not a cliff. Not every finding is an immediate
   blocker. The harness supports warn → error severity promotion so you can
   report debt on day one and enforce it incrementally as cleanup lands.

4. Reuse across packs. The harness accepts --root and --config flags to audit
   any pack from a single checkout. The portable unit is scripts/stack-health.ts +
   stack-health.config.json. An example config for a generic agent pack is included
   in docs/examples/.

In short: adding a Health Harness allows for the protection of users from dark patterns .

Why master is needed on the fork

The upstream repo uses main as its default branch. This fork maintains both
main (tracking upstream) and master for two reasons:

1. Continuous Deployment (CD) target. master serves as the fork's own stable
   deployment branch — the audited, harness-passing state that gets installed into
   ~/.claude/skills/gstack/. Upstream main moves independently and may introduce
   new egress surfaces or policy regressions between audits. master only advances
   when the harness passes and the delta has been reviewed.

2. Record master / audit trail. master acts as the canonical record of what
   has been reviewed and cleared. Each advance of master represents a deliberate
   decision: "this state has passed integrity checks, egress audit, and manipulation-
   pattern policy." It's the branch you point compliance and audit tooling at and not
   the fast-moving upstream main that may contain unreviewed changes.

In short: main tracks upstream for easy rebasing; master tracks audited state
for deployment and accountability.