fix: extract --json always carries the extraction inline

[yzld2002]

Closes #189

What I found

The two paths are not separate code: fresh completions and cached hits both
render through the single emit_summary in extract.py, and extraction is
built unconditionally from the same dict on both — the response result on a
fresh run, the byte-identical extract.json on a cached one. Driving both
paths through the CLI seam across every input form (parse item, extract -d
reuse, extract -d parse-first, --markdown, --markdown-url) and a forced
re-extract, the payloads come out key-for-key and value-for-value identical
apart from cached, with extraction inline in each. The reported summary
shape does not reproduce, and no version of this repo can produce it: the key
has been unconditional since the first commit, on every branch and every tag,
so there is no maintainer evidence of an intentional summary shape to
document — the contract stands as written.

What was actually broken

There was one way a successful run could reach stdout with no result in it: a
completed body whose result carried no extraction. The summary read it
with .get, so the run reported status: extracted, billed, wrote an
extract.json with no result in it, and printed extraction: null — silently
handing a consumer a payload it cannot read, which is the failure the issue
describes from the consumer's side.

That now fails whole in the consume-before-write block, next to the existing
extraction_metadata and markdown-echo guards: unsupported_result_schema,
the ticket marked unreadable with the reason, no artifact written, and a
re-run that re-polls the same job instead of re-billing.

Changes

• extract.py: a completed result with no usable extraction (key missing,
  or not an object/array) is rejected before any write, instead of reporting
  a billed success with extraction: null.
• tests/test_extract.py: parity tests pinning fresh ≡ cached payload shape
  across the input forms and a forced re-extract, plus the regression test
  for the guard (fails on main, both parametrisations).
• help.py + docs/reference/help.json: ade help extract --json now says
  outright that extraction is inline on every successful run, cached hits
  included.

Notes

• Full offline suite green (749 passed, 8 skipped); ruff and ty clean.
• Pre-existing items whose stored extract.json has no extraction (written
  before this guard) still serve extraction: null on a cached hit. Nothing
  can create one from here, so I left the store read alone rather than have a
  cached hit re-bill.
• Unrelated, spotted while reading the same help block: credits is
  documented as "0 on a cached hit", but both parse and extract report the
  original bill on a cached hit. Left alone here.

🤖 Generated with Claude Code