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

PEER_CLI_SCENARIOS.md

@@ -122,6 +122,10 @@ Use S39-S41 to pin down low-disk streamed installs:
 - Non-solid and solid archives both install into `local/` without committing a
   root archive or root `version.ini`, so the receiver is installed but not a
   downloadable source.
+- Streamed install integrity is currently sender archive integrity: size and
+  RAR CRC32 must match the sender's archive metadata. The SHA-256 checks in the
+  scenarios prove the Docker/provider path matches the source fixture; they are
+  not catalog-owned trust anchors.
 - S41 verifies the fixture is actually solid inside the source container, so
   solid handling stays covered by the same Docker harness as the existing
   streamed-install scenarios.