Blocker report: a full version for the customer plus an anonymized version they can send us to feed the engine-fix loop #5054

Why. When a customer runs a zero-gap scan on their own machine, two people need the blocker list:

1. The customer, who needs every detail (files, programs, symbols, copybooks, tables) to work through their own tickets.
2. Us, because their blockers are what tell us where the engine has to improve next. Customers won't send us source code or their names for things, so today we have no way of seeing what blocked them.

So the report should come in two forms from one run: a full report that stays with the customer, and an anonymized one they can send to us safely. The anonymized report then feeds our own engine-fixing loop (the churn/shepherd harness), the same way our own estates do today.

What.

• Full report. Everything Equivalence harness: self-report coverage, run status and actionable blockers as a generated .md page #4493 describes: coverage, run status per program, and blockers stated as fixes, with the files, symbols and unlock counts named. This one never leaves the customer's machine.
• Anonymized report. Generated from the same data in the same run (--anonymize, or always written next to the full one) as Markdown + JSON. It keeps the shape of each blocker and removes anything that identifies the customer:
  • Kept: the blocker category and sub-class (layout / non-VSAM input / cross-record rule / unresolved link / environment / CICS command family / dialect …), the construct signature (e.g. EXEC CICS READQ TS … NUMITEMS, REDEFINES selected by sibling field, RECFM V), counts (programs blocked, tests unlocked, how often it occurs), the engine and rule-catalogue version, and refusal codes.
  • Removed: program, copybook, file, dataset, table, queue, transaction and field names; literals and comments; paths; and any source lines.
  • Hashed instead of dropped: identifiers become a salted hash (PGM_7f3a, TBL_19c2), with one salt per customer kept on their side. Their runs can then be compared over time ("this blocker is still open after 3 releases"), but nothing can be matched across customers or reversed.
  • A small minimal repro where possible. For example, a synthetic COBOL/CICS snippet built from the construct signature with made-up names, so we can reproduce the blocker without their code.
• A manifest the customer can review. It's a short list of exactly what fields the anonymized file contains, so their security team can approve sending it, plus a --redact-more option to drop sub-classes or counts if they want.
• Ingestion on our side. We need a command that takes a customer's anonymized report and turns each blocker into a ledger row (Ledger: tag port blockers (det / forge / facade / harness) by the estate that exposed them, beside field_testing.json's defects #5051, with estate: customer:<hash>), linking it to an existing issue when the construct signature matches one, or opening a new one when it doesn't. The anonymized report becomes one more input to the churn queue.

Done when:

1. One run writes both reports. Every blocker in the full report appears in the anonymized one under the same category, with the same counts.
2. A leak test passes. On a fixture estate, scan the anonymized output for every identifier, literal, comment and path in the source, and fail if any of them appear. This runs in CI on the crucible estates (CardDemo, GenApp, CBSA, zECS, cics-crucible).
3. The hashes don't change between runs with the same salt, and they do change with a different salt.
4. Ingesting an anonymized report from one of our own estates creates ledger rows that match the blockers we already know that estate has.
5. The anonymized format is documented as a public schema with a version, so customers can audit it.

Related: #4493 (generated blocker page; this is its full form plus a twin that's safe to send), #5051 (port-blocker ledger; where ingested reports land), #5052 (economics of the iterative loop), #4724 (readiness scanner support matrix), #4055 (product is the proof).