Add JSON output to recall search - #379

Approving. This is a clean, well-scoped addition: the JSON path is additive, the human output is untouched, and the field set is an exact match for recall objects --json, which is what makes the two feeds interchangeable for a headless consumer.

What I verified locally (worktree at dfce771, merged trial against main)

• cargo test --test objects_e2e search_ : 8 passed, including the new search_json_emits_typed_hits_and_an_empty_array.
• cargo clippy --all-targets --all-features -- -D warnings : clean.
• python3 scripts/gen_manual.py : regenerates docs/manual/index.html byte-identically, so the committed HTML is genuinely fresh and the manuals fresh (man + html) gate will pass.
• ./scripts/gen_man.sh : man/man1/h5i.1 unchanged, as expected. recall is a [REST] passthrough in the clap tree, so verb-level flags never reach the man page. No man regen was needed here.
• Trial merge with current main : clean.

Design notes

• Field parity with ObjJson is exact (14 fields, same names, same skip_serializing_if), and .take(limit) matches the human path, so --limit behaves identically in both modes. Good.
• Emitting the full matched finding set per capture (rather than the human path's PER_CAPTURE = 8 cap) is the right call for a machine feed: a consumer that wants every hit should not have to fall back to recall object <id>.

Non-blocking suggestions

1. Drift risk in the duplicated struct. SearchJson restates every ObjJson field. The next field added to recall objects --json will silently not appear in recall search --json, and nothing in the test suite would catch it. Consider one shared struct with an optional findings slot:

   #[serde(skip_serializing_if = "Option::is_none")]
   findings: Option<Vec<&'a h5i_core::structured::Finding>>,

   plus a small fn row(m: &Manifest, store: &LocalStore, findings: Option<...>) -> ObjJson used by both arms. That also removes the third copy of the serde_json::to_value(status) round-trip, which already exists as the private objects::enum_str in h5i-core; making that pub would let both call sites share it.

2. Silent truncation. When hits.len() > limit the human path prints — showing {limit}, but the JSON array just ends, so a consumer cannot distinguish 20 results from 20-plus. This matches recall objects --json exactly, so I would not change it in this PR; worth considering a truncated marker for both feeds later if CI graders start paging.

Nothing here blocks the merge. Thanks for including the zero-match [] case and the MANUAL.md capability-table row, both of which are easy to forget.