fix(beads): batch graph issue reads within capture limits (FUZZ-015 r3)

[randlee]

Fixes comp-t-7.27 (campaign run 3 FUZZ-015 residual): the graph read queries bd show in batches of at most 64 ids, so the per-id not-found stderr of a 350-500 step plan stays within the unchanged 64 KiB stderr cap. Large attaches, re-runs and preview-attaches no longer hit BEADS_PROCESS_OUTPUT_LIMIT. Regression test uses a fake bd that writes a not-found line per missing id.

Rebased 4f3681b -> 4f13497 onto #722. Gates at 4f13497: clippy -D warnings clean, fmt clean, cargo test --workspace 1074 passed / 0 failed / 0 ignored.

🤖 Generated with Claude Code

[randlee]

QA fix verification: comp-t-7.27-qa (FUZZ-015 residual) at 4f13497

Verdict: PASS. 1 carried finding verified fixed.

Finding	Disposition
FUZZ-015	fixed

The fuzz coordinator, locked to FUZZ-015, verified at the pinned commit through the real CLI against a fake-bd stub (argv logged, one Error fetching <id>: issue not found: <id> stderr line per missing id):

• Large plans: preview-attach and attach exit 0 at 1, 36, 40, 350 and 500 steps, and at 2000 steps (32 show batches, 1.8s preview, 1.2s attach). Baseline d2c5704 fails a same-shaped 500-step attach with BEADS_PROCESS_OUTPUT_LIMIT (69,284 bytes of stderr in one show call).
• Batching: 500 steps issue 8 show --json -- <ids> calls (64 ids x 7, then 53). All 501 ids (500 plan ids plus parent) are queried exactly once, in sorted and run-stable order, with the -- separator kept. Every dep list call comes after the last show; create comes last.
• Caps unchanged: the diff touches only graph.rs and the test file; runner.rs is untouched. 64 KiB (PROCESS_OUTPUT_LIMIT_BYTES) and 16 MiB (GRAPH_OUTPUT_LIMIT_BYTES) are unchanged. A single batch with 70,000 bytes of stderr and a stub with 17 MiB of stdout both still return BEADS_PROCESS_OUTPUT_LIMIT, as baseline, with no create.
• Existing ids: for 1, 36 and 40 steps with none, some or all ids existing, normalized receipts, exit codes and argv sequences match baseline. A 500-step run with every third id existing merges correctly. A bd failure in batch 2 or batch 8 returns BEADS_GRAPH_READ_FAILED, stops after that show, and makes no create call.
• Tests: 4 fuzz_015 tests pass, none ignored; 3 of the 4 fail when copied onto the baseline (the 40-step one passes there, as expected). Full cargo test -p sc-composer-beads passes. Local fmt, clippy -D warnings and tests for sc-composer, sc-composer-beads and sc-compose are clean at this head.

Notes, not findings:

• A 500-step re-run where every id exists takes 8.5s (preview) to 12.3s (attach) because dep list runs once per existing step (500 spawns). That was already the case before this change; batching or parallelising it is a possible follow-up.
• The stub's stderr line is about 80 bytes; baseline only fails at 500 steps when lines are about 140 bytes or more. Real bd's per-line size should be confirmed.

Disclosures: fake-bd stub, not real bd 1.3.1; real exit codes and stderr for a mixed batch are unverified. CI not checked (rate-limit rule).