Build the june-1 FAIL.txt report generator into the mechababs CLI

The june-1 shakeout's `8-fail-report.sh` (since deleted; source in git history) read the ledger and wrote a per-failed-stage `reports//--FAIL.txt`, classifying on the failure signal:

- **job-failed** ("zip not found" → the job ran + crashed → tail the SLURM logs)
- **submit-error** (never queued → tail the duct wrapper logs)

Reincarnate this as a campaign CLI capability — an `iterate` failure-reporting step, or a `mechababs report` subcommand — driven off the ledger + `babs status`/RIA.

**Fold in the grep + tail lesson (do both, not either/or):** grep for known crash signatures (`Traceback`/`Error`/`CANCELLED`) so a fixed `tail` that lands past the crash line doesn't hide it — **and keep the tail too**. Grep alone isn't trusted to catch a novel failure mode; the tail usually does cover the crash. So the report shows both: the grep hits + the log tail.

Reports are a campaign *output* → they land in the campaign dataset, never back in `code/mechababs`.

cf #53 (duct-wrapped per-step logs give the report its inputs), #3 (resource actuals from the same duct logs), #13 (done/failed state).

Read the deleted 8-fail-report.sh from git history, then trace how the CLI accesses the ledger and babs status/RIA. Inspect the duct-wrapped per-step logs and ensure reports land in the campaign dataset, showing both known-signature grep hits and the relevant log tail for job-failed and submit-error cases.

Written by the indexing model from the issue text.