SHINES signed-path attachments (signed hash manifest)
## Summary
Add attachment support to the standalone-SHINES **signed/mandated** intake path using a **signed SHA-256 hash manifest**, a **single multipart request**, and **server-side edge verification**. The reporter's existing detached JWS covers a manifest of file hashes, so documents are tamper-evident without signing the upload transport; craig-intake recomputes the hashes from the received bytes, verifies them against the signed manifest, and forwards report + files to SHINES atomically. Today the SHINES portal drops attachments entirely.
## Plan
[docs/modules/ROOT/pages/plans/shines-signed-attachments.adoc](https://gitlab.com/gadhs/application/ccwis/craig/-/blob/main/docs/modules/ROOT/pages/plans/shines-signed-attachments.adoc)
## Children
- [x] #940 feat(intake): SHINES attachment contracts + validation (weight: 5)
- [x] #941 feat(intake): signed handler content-negotiating multipart + edge hash verification (weight: 8)
- [x] #942 feat(intake): forward SHINES attachments as multipart to the sink + mock branch (weight: 5)
- [x] #943 feat(intake): expose recomputed hashes + signed manifest in debug output (weight: 3)
- [x] #944 feat(intake): SHINES portal attachment upload UI (weight: 5)
- [x] #945 feat(sdk): signed-multipart attachment submit (Python + TS + Rust) (weight: 5)
- [x] #946 docs(intake): ADR-042 + proposed API + e2e + baselines (final MR) (weight: 3)
Scope: signed/mandated path only. Out of scope: unsigned attachments, cases-backed changes, any `GET /{id}/attachments` retrieval endpoint.
epic