jobs: log which check rejects a manifest

[colinmegill]

Observable change

When the job daemon refuses a claimed attempt's output manifest, it now writes one polis_jobs.manifest_reject/1 log line naming the specific check that failed — a manifest-validator field (e.g. the manifest is too large, or a bad embedding-spool descriptor), a result-staging check (the embedding spool, a family spool, a digest, a byte bound, a receipt), or a finalize-time invalid_output. The attempt's transition reason and the poison code are unchanged (manifest_invalid); this is an additional, additive diagnostic line on a distinct schema, kept out of the transition stream its readers parse.

Why

A refused manifest was recorded only as manifest_invalid, with every distinct cause collapsed to that one opaque reason and nothing else logged. When a large conversation's result manifest was refused, it was not possible to tell from the daemon's log which check rejected it. This line makes a rejection diagnosable from the log alone.

Scope / safety

• No bound, schema, or transition field changes. Poison detection (is_poison_code) and the polis_jobs.transition/1 schema are untouched; the stored pq_fail reason stays manifest_invalid.
• The new line is emitted only on the rejection paths; a successful attempt logs nothing new.
• The participation path (votes, comments, next statement) is not touched.

Tests

• cargo fmt --check, cargo clippy --all-targets -D warnings (default and jobs-integration), cargo test (unit + the jobs_integration suite). The refused-manifest integration test now asserts the daemon log names a check.
• The production-import proof at ~102 MB (9,500 384-dim comments; codec family 102,767,341 bytes) and the real-model embeddings-table proof both pass unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_018NVGBuYCk4EZmiz4csUv9s