docs: record the CI consequences of the M10.6 TLS dependency

ci-requirements.md is the contract with CI-Runner (rule 39), so the two
things a future image change could silently break belong in it:

libssl-dev + pkg-config in ci-tauri are now load-bearing — native-tls
compiles against OpenSSL on Linux, so a slim-down of that image would fail
the Rust build at openssl-sys rather than anywhere obvious.

The TLS backend choice is a property of the WINDOWS lane, not a dependency
detail: native-tls resolves to schannel on windows-msvc, keeping C/assembly
out of the cross-compile. Swapping to rustls would pull in ring/aws-lc-rs
and their assembler — the same class of dependency that broke that lane
before. Flagged so it's treated as a lane change, not a version bump.

Also documented why libssl3 is left covered TRANSITIVELY rather than
declared. dpkg-shlibdeps now lists it, and verify.sh passes it through
webkit's recursive closure. Declaring it directly would be worse, not
better: the package name is release-dependent (libssl3 on bookworm,
libssl3t64 after the time_t transition), so hardcoding it freezes the .deb
to the build distro, whereas webkit's closure adapts. verify.sh fails loudly
if webkit ever stops pulling OpenSSL, which is what makes that safe.

Docs only — triggers no workflow.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi

ci-requirements.md

@@ -78,6 +78,22 @@ backend/frontend push.
   `pacman -Qkk` file verification needs `.MTREE`. Adding `libarchive-tools` +
   `zstd` + a docker CLI to `ci-tauri` would upgrade these paths; none of them
   block a green build.
+- **`libssl-dev` + `pkg-config` are load-bearing** (both already in `ci-tauri`).
+  Since M10.6 the desktop crate depends on `reqwest` with the **`native-tls`**
+  backend, which on Linux compiles against OpenSSL. Do NOT drop either package
+  from `ci-tauri` in a future slim-down — the Rust build fails at `openssl-sys`.
+  (They're part of Tauri's own documented Linux prerequisites, so they should
+  stay regardless.)
+- **`libssl3` is covered transitively, on purpose — don't "fix" it.** Since
+  M10.6 `dpkg-shlibdeps` lists `libssl3` among the binary's needs, but the
+  `.deb` declares only `libwebkit2gtk-4.1-0` + `libgtk-3-0`. `verify.sh` passes
+  it because webkit's own recursive dependency closure includes OpenSSL, so apt
+  installs it either way. Declaring it explicitly would be *worse*: the package
+  name is release-dependent (`libssl3` on bookworm, `libssl3t64` after the
+  64-bit-time_t transition in trixie/Ubuntu 24.04), so a hardcoded name freezes
+  the package to the build distro. Leaning on webkit's closure adapts. If webkit
+  ever stops pulling OpenSSL, `verify.sh` fails the build loudly — that guard is
+  what makes the indirection safe.
 - **Not verifiable in CI:** the runner is Debian, so the pacman package cannot be
   `pacman -U`-tested here. That step logs `.PKGINFO` + the full file listing so
   the package is auditable from the run log; a real Arch install is the operator's
@@ -106,5 +122,12 @@ backend/frontend push.
   mandatory before trusting a release.
 - **Unsigned.** Installers will trip SmartScreen until a code-signing
   certificate exists; that is a purchasing decision, not a CI one.
+- **TLS backend is chosen for this lane's sake.** The desktop crate pins
+  `reqwest` to `native-tls`, which on `x86_64-pc-windows-msvc` resolves to
+  `schannel` — pure-Rust bindings to the OS TLS stack. That keeps C/assembly out
+  of the cross-compile entirely. Switching to `rustls` would pull in
+  `ring`/`aws-lc-rs` and their assembler, which is exactly the class of
+  dependency that broke this lane before (`libsqlite3-sys` → `llvm-lib`). Treat
+  a TLS-backend change as a change to *this lane*, not just a dependency bump.
 - No Postgres lane (unchanged): the desktop app's local store + sync behavior is
   verified on the operator's machine, not in CI.