Pre-#596 the project relied on user-reported real-world programs
to surface scale-dependent codegen/runtime bugs — #570 (iterative-
builder shadow-stack overflow at ~4000 elements), #515 (GC self-
fault under sustained allocation), #593 (Conway's Life corruption
at 12×30+), and others.  The standard test suite has thousands of
small focused tests but none that exercise the runtime at scales
where these bugs first manifested.  This PR closes that gap with
a dedicated stress-test harness.

What ships:

1. **`tests/test_stress.py`** with 8 scale-dependent regression
   tests, each hitting a specific scale axis:

   - 10K `array_map` over `Array<Int>` — shadow-stack overflow
     (#570)
   - 5K nested-array `array_map` over `Array<Array<Bool>>` —
     per-iteration root accumulation (#570/#515)
   - 1K-deep tail recursion with allocating String arg — TCO/GC
     interaction (#549)
   - 20×20 nested array-fold-of-array-fold — #593/#595 regression
     coverage (the structural shape that hit those bugs, not the
     bug-report program itself)
   - 100K `array_fold` over Int array — allocation pressure
     (#487/#348)
   - 10K String allocations through interpolation — wrap-table
     compaction (#573)
   - 1K `State<Int>` get/put cycles in single handler — handler/
     resume plumbing under load
   - 10K `IO.print` calls with stdout-capture — host-import call
     rate, capture buffer growth

   Each test asserts on a SPECIFIC observable (closed-form sum,
   exact line count, etc.), not just "completed without
   crashing", so a future regression that silently short-circuits
   or skips iterations would still fail.

2. **`stress` pytest marker** registered in `pyproject.toml` with
   default `addopts = "-m 'not stress'"` — stress tests are
   skipped from the per-PR pytest run.  Local invocation:
   `pytest -m stress` or `pytest tests/test_stress.py -m stress
   -v`.

3. **`.github/workflows/nightly-stress.yml`** with three triggers:

   - Nightly cron at 06:00 UTC (primary safety net)
   - Path-filtered PRs touching `vera/codegen/**` /
     `vera/wasm/**` / `tests/test_stress.py` / the workflow
     itself (fail-fast on PRs likely to break stress invariants)
   - Manual `workflow_dispatch` (Actions tab)

4. **"Stress tests" subsection in `TESTING.md`** documenting the
   8 test programs with their scale axes, the default-skip
   behaviour, the three CI triggers, and the assertion-shape
   convention.

5. **`scripts/check_doc_counts.py` fix** — added `-o addopts=""`
   to the collection-only call so the script sees every test
   file including `test_stress.py` (without this override, the
   default `-m 'not stress'` filter would deselect stress tests
   and the per-file counter would report `test_stress.py` as a
   missing row).

6. **ROADMAP cleanup** — removed #596 from Order 1 in the
   Stabilisation tier (now closed by this PR).  Tier renumbered
   1-5 (was 1-6).  Agent-integration tier renumbered 6-8 (was
   7-9).

Release prep:

- Version bumped to v0.0.152 across `__init__.py`,
  `pyproject.toml`, `uv.lock`, `docs/index.html`, `README.md`.
- CHANGELOG.md entry under `[0.0.152]` with Added + Documentation
  sections.
- HISTORY.md row added (one-line template-compliant).
- TESTING.md overview totals updated (3,863 → 3,871 tests,
  31 → 32 files).
- ROADMAP.md test count updated to 3,871.

Validation:

- `pytest tests/test_stress.py -m stress -v` → 8 passed in 0.25s
- `pytest tests/ -q` → 3,849 passed, 14 skipped, 8 deselected
  (stress filtered out by default addopts)
- `mypy vera/` → clean
- `python scripts/check_walker_coverage.py` → 9 walkers, all 29
  Expr subclasses covered
- `python scripts/check_doc_counts.py` → consistent (3,871
  tests, 32 files, 27 hooks, 7 CI jobs)
- Doc sweep across SKILL / CLAUDE / AGENTS / README / vera/README
  / CONTRIBUTING / spec / docs / examples → zero stale "stress
  tests missing" claims

Closes #596

Co-Authored-By: Claude <noreply@anthropic.invalid>

User feedback on #669: the initial Stress Tests subsection had
the summary table + behaviour blurb but not per-test detail.
Expanded the section to cover, for each of the 8 tests:

- The exact program shape (what it allocates, what loop it
  drives, what it folds/maps/iterates over)
- The expected return value and the assertion's *closed-form*
  derivation (e.g. why `test_10k_string_allocations` should
  return 38,890 — broken down by digit-count contribution)
- The specific bug class it guards against, with issue
  references
- Why the chosen iteration count is meaningful relative to
  that bug class's historical failure threshold

Also added an "Adding a stress test" subsection codifying the
conventions:

1. Target a specific scale axis + name the bug class
2. Pick the smallest scale with ~2-3x safety margin (don't
   maximise)
3. Assert on a SPECIFIC observable with closed-form expected
   value (avoid "no exception raised")
4. Use the `_run` helper for tempfile lifecycle
5. `pytestmark = pytest.mark.stress` at module level for
   correct gating

Plus reformatted the local-invocation block as a fenced bash
example so the three useful invocations (full stress, file-
scoped, single-test) are copy-pasteable.

Validation
- `python scripts/check_doc_counts.py` -> consistent (no
  count-affecting numbers changed)

Refs #596 #669

The #596 issue body explicitly called for a subset of stress
tests to run under `VERA_EAGER_GC=1` to catch GC-rooting
regressions on the very first iteration rather than only at
scale.  I missed that requirement in the initial PR and the
user surfaced it.

Implementation:

- `EAGER_GC_PARAMS = pytest.mark.parametrize(...)` decorator
  with `eager_gc: [False, True]` and IDs `["default_gc",
  "eager_gc"]` exposed at module level for the subset of
  tests targeting GC-rooting bug classes.
- `_run` helper extended with `eager_gc: bool` +
  `monkeypatch: pytest.MonkeyPatch | None` keyword args.  When
  `eager_gc=True`, calls `monkeypatch.setenv("VERA_EAGER_GC",
  "1")` before the `compile()` call.  `VERA_EAGER_GC` is read
  at compile time by `vera/codegen/assembly.py::_emit_alloc`,
  which then emits a `call $gc_collect` as the first
  instruction of the runtime's `$alloc` function — forcing a
  full GC pass on every allocation.
- 6 of the 8 logical tests carry `@EAGER_GC_PARAMS` and the
  paired signature `(eager_gc: bool, monkeypatch: pytest
  .MonkeyPatch)`:
    - `test_array_map_over_10k_int_array` (#570 target)
    - `test_array_map_over_5k_nested_bool_array` (#570/#515
      target)
    - `test_deep_tail_recursion_with_allocating_arg` (#549
      TCO/GC target)
    - `test_conways_life_20x20_100_generations` (#593/#595
      target)
    - `test_10k_string_allocations` (#573 wrap-table target)
    - `test_state_handler_1k_ops` (captured-frame target)
- 2 tests stay un-parametrised — `test_array_fold_100k_
  iterations` (allocation-pressure target, NOT GC-rooting;
  100K forced-GC would inflate suite time) and
  `test_10k_io_print_calls` (host-import target; `host_print`
  bridge doesn't allocate Vera-heap data).
- Total test count: 8 logical × eager lane parametrisation on
  6 of them = 14 test instances.  Wall-clock 0.66s in-process
  for the full suite.

Documentation updates:

- TESTING.md: new "Eager-GC lane" subsection explaining the
  mechanism, the subset rationale, and the parametrize-with-
  monkeypatch implementation.  Per-test descriptions in the
  inventory marked with `**[eager-GC]**` for the parametrised
  6 and explicit "Not in eager-GC lane" notes for the 2
  excluded.  "Adding a stress test" checklist gained a new
  step 6 codifying the opt-in convention.
- CHANGELOG.md v0.0.152: extended with a new bullet describing
  the eager-GC lane mechanism and the subset rationale.
- Test counts auto-updated: 3,871 -> 3,877 (+6 parametrised
  instances), test_stress.py 8 -> 14 tests, 375 -> 469 lines.

Validation:

- `pytest tests/test_stress.py -m stress -v` -> 14 passed in
  0.64s (was 8 passed in 0.25s)
- `python scripts/check_doc_counts.py` -> consistent
- `python scripts/check_walker_coverage.py` -> clean
- `python scripts/check_version_sync.py` -> consistent

Refs #596 #669

The original #596 spec covered CI integration but didn't cover
reporting — a cron-failure would be visible only to whoever
opened the Actions tab and noticed.  This is fragile for an
early-warning system.

Adds an `Open or update tracking issue on cron failure` step to
`.github/workflows/nightly-stress.yml` that runs only on
`schedule`-triggered failures (skipped on `pull_request` and
`workflow_dispatch` — those have their own reporting surfaces):

1. Ensures the `stress-regression` label exists (idempotent,
   creates on first failure with description and red colour).
2. Searches for an open issue carrying the label.
3. If one exists: appends a comment with the new commit SHA +
   run URL, so the original tracking issue accumulates the
   failure history.
4. If none: files a fresh issue titled "Nightly stress
   regression on main (tracking)" with the SHA, run URL, and
   pointer to `tests/test_stress.py` for the failing test's
   docstring (each test names the bug class it guards
   against — narrows the regression family for the bisector).

Open tracking issues stay open across days until manually
closed.  Auto-closing on success would be wrong while a
maintainer is mid-debug.

Job-level permission `issues: write` added (scoped to the job,
not workflow-wide, so the test-runner step keeps the tighter
`contents: read` default).  Implementation uses
`actions/github-script@v7` which only sees GitHub-controlled
values (`github.sha`, `github.server_url`, `github.repository`,
`github.run_id`) — no user-supplied input in the script body.

Documentation:

- TESTING.md "Stress Tests" section's CI-integration bullets
  updated to describe the auto-filing behaviour + a new
  "Failure reporting (cron only)" subsection describing the
  dedup logic, the issue lifecycle, and the implementation
  details.
- CHANGELOG.md v0.0.152: added a bullet describing the
  failure-reporting wire-up.

Validation:

- YAML parses (`python -c 'import yaml; yaml.safe_load(...)'`)
- 5 steps in the job (was 4); failure-reporting step gated on
  `failure() && github.event_name == 'schedule'`
- Stress suite still 14/14 pass

Refs #596 #669

**CR-C** (`.github/workflows/nightly-stress.yml:131-140`) —
`listForRepo` dedup query returned both issues and PRs.

`github.rest.issues.listForRepo` with a label filter returns
any item carrying the label, including PRs (the GitHub API
models PRs as issues with a `pull_request` field).  If a PR
were ever labelled `stress-regression`, the workflow's dedup
branch would post the failure comment on the PR instead of
filing a fresh tracking issue.

Real risk is low — the `stress-regression` label is only
applied by this workflow today — but the fix is cheap and
defensive: filter the result list to exclude items with a
`pull_request` field set.  Renamed the `existing` const to
`candidates` (the raw API result) and built `existing` as the
filtered subset, then the rest of the dedup logic continues
unchanged.

Skipped CR's additional suggestion of filtering by exact title
match (`i.title === EXPECTED_TITLE`).  Rationale: the label
is already the dedup primary key, and a strict title filter
would break dedup if a maintainer renames the tracking issue
(e.g. to "Nightly stress regression — fixed by PR #N").
Defaulting to "label is enough" is more forgiving for the
expected human workflow.

**CR-D** (`TESTING.md:354-355` and parallel sites) —
misattributed #595 citation on the Conway's Life stress test.

CR's investigation surfaced an inconsistency: line 88 maps
#595 to IO.sleep/KeyboardInterrupt handling, but my line 354
described the Conway's Life stress test as covering "#593 and
#595 (malloc abort during wasmtime cleanup)".  Verified
against the CHANGELOG record (entries at lines 248 and 283
trace #595 to a cleanup-path bug fixed by an upstream wasmtime-
py change, not a Conway's Life data-integrity bug): #595's
regression coverage lives in `TestHostSleepKeyboardInterrupt`
in `tests/test_runtime_traps.py`, NOT in this stress test.

The Conway's Life stress test:
- Uses `effects(pure)` (no Ctrl-C, no IO.sleep)
- Completes normally (no wasmtime-cleanup signal escape)
- Therefore exercises NONE of #595's code paths

The misattribution came from the original #596 issue body
which paired the two issues as "scale-dependent runtime bugs";
when I lifted the pairing into the test description I didn't
re-verify whether the structural shapes actually matched.

Fix: drop the #595 reference from this test's description in
4 places — `tests/test_stress.py` docstring (2 sites: header
paragraph + body comment), `TESTING.md:354` (per-test
description), `TESTING.md:69` (test-file-row's `Pins ...`
list), `CHANGELOG.md` (the v0.0.152 Added paragraph).  Added
an explanatory "Note on #595" block in the test docstring +
parallel parenthetical in TESTING.md so a future reader
understands why the citation was dropped (and doesn't re-add
it).  CHANGELOG historical entries (lines 248, 283) that
reference #595 in its OWN bug-history context are unchanged
— those are accurate descriptions of #595 in its proper
domain.

Doc counts: test_stress.py 479 → 487 lines (docstring
expansion for the #595-misattribution note).

Validation:
- YAML parses (`yaml.safe_load` on the workflow)
- `pytest tests/test_stress.py -m stress -q` → 14 passed in
  0.65s
- `python scripts/check_doc_counts.py` → consistent
- No residual #595 references in PR-touched files outside the
  intentional historical "Note on #595" explanatory blocks

Refs #596 #669