refactor(peer): name streamed integrity boundary

NEXT_STEPS item 4 needed the streamed-install integrity model to be a
conscious decision. Keep the current runtime behavior, but name it as
sender archive integrity: the receiver verifies streamed file size and
RAR CRC32 from the sender's archive metadata before committing the
install transaction.

This protects against truncation, transport corruption, and stream
provider bugs. It deliberately does not claim malicious-peer protection,
because the sender controls both the streamed bytes and the RAR metadata.
The docs now say that trusted content requires a future catalog schema
with catalog-owned archive or extracted-file SHA-256 hashes.

Test Plan:
- just fmt
- just test
- just clippy
- python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S41 --build-image
- git diff --check
- git diff --cached --check

Refs: NEXT_STEPS.md item 4

NEXT_STEPS.md

@@ -29,12 +29,14 @@ product-ready.
    peer-cli flow, including local-only final state, absent root archive/sentinel,
    byte count, and extracted payload SHA-256 hashes.
 
-4. **Decide the integrity model**
+4. **Done — Decide the integrity model**
 
-   Current prototype verifies streamed bytes against RAR CRC32 from the
-   sender’s archive headers. That catches corruption and provider bugs. It does
-   not protect against a malicious peer lying. If you care about that, the next
-   step is catalog-side trusted hashes for archive or extracted files.
+   Streamed installs intentionally verify against sender archive metadata for
+   now: each file must match the RAR-advertised size and CRC32. That catches
+   transport corruption, truncation, and provider bugs, but does not claim
+   malicious-peer protection. Trusted content remains a separate catalog schema
+   step: add catalog-owned archive or extracted-file SHA-256 hashes, then verify
+   those at the receiver before commit.
 
 5. **Upgrade retry/resume semantics**