fix(flatpak): prune pf-client-core's windows-rs git dep from the sandbox manifest — offline build broken since a69a83b5

The flatpak's offline cargo build has failed on every run since the D3D11VA push:
pf-client-core now declares the same git-pinned `windows` dependency as the Windows
client (cfg(windows)-gated, never compiled on Linux), and `cargo --offline` needs
every DECLARED dependency's source just to build the unit graph — but windows-rs is
deliberately not vendored into cargo-sources.json (flatpak-builder would full-clone
the multi-GB repo; the reason prune-windows-lock.py exists). Removing the workspace
member alone no longer covers it.

New packaging/flatpak/prune-windows-toml.py (dependency-free, like its lock sibling)
strips windows-rs git entries from a manifest in place — single- or multi-line —
and the flatpak manifest runs it on crates/pf-client-core/Cargo.toml right after the
existing clients/windows member sed. Registry deps in the same cfg(windows) table
(wasapi, sdl3) are kept; they vendor normally.

Verified in a scratch worktree with both prunes applied: the TOML stays valid and
`cargo metadata` resolves ZERO windows-rs packages and zero git-source declarations
— nothing left for --offline to fetch. End-to-end proof is the flatpak CI run on
this push.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

packaging/flatpak/io.unom.Punktfunk.yml

@@ -172,17 +172,19 @@ modules:
         # invocation doesn't inherit the SDK's default include search, so pass it explicitly).
         PF_FFVK_VULKAN_INCLUDE: /app/include
     build-commands:
-      # Drop the Windows client from the workspace before building. It pins windows-rs as a
-      # git dependency (cfg(windows)-gated, but cargo resolves it for the whole workspace
-      # regardless of target), and that git source is deliberately NOT vendored into
-      # cargo-sources.json — see packaging/flatpak/prune-windows-lock.py, which strips it so
-      # flatpak-builder doesn't full-clone the multi-GB windows-rs repo. Without removing the
-      # member, `cargo --offline` would try to load the un-vendored windows-rs source and fail
-      # ("can't checkout ... you are in the offline mode"). The flatpak never compiles the
-      # Windows client; this edits only the sandbox copy of Cargo.toml. (No --locked: the lock
-      # no longer matches the reduced member set; --offline still pins every crate to the
-      # vendored cargo-sources.json, so the build stays reproducible.)
+      # Drop every reference to the windows-rs GIT dependency before building. That git
+      # source is deliberately NOT vendored into cargo-sources.json — see
+      # packaging/flatpak/prune-windows-lock.py, which strips it so flatpak-builder doesn't
+      # full-clone the multi-GB windows-rs repo. But `cargo --offline` needs every DECLARED
+      # dependency's source just to build the unit graph (cfg(windows)-gated or not), so any
+      # manifest still pinning it fails with "can't checkout ... you are in the offline
+      # mode". Two declare it: the Windows client (removed from the workspace members) and
+      # pf-client-core's D3D11VA backend (entry pruned in place — nothing cfg(windows)
+      # compiles here). Both edits touch only the sandbox copies. (No --locked: the lock no
+      # longer matches the reduced graph; --offline still pins every crate to the vendored
+      # cargo-sources.json, so the build stays reproducible.)
       - sed -i '\#"clients/windows",#d' Cargo.toml
+      - python3 packaging/flatpak/prune-windows-toml.py crates/pf-client-core/Cargo.toml
       # One cargo invocation for both binaries: the shell and the Vulkan session binary it
       # execs for --connect/--browse. Building them together keeps skia-bindings' feature
       # unification identical to a workspace build (the pinned skia-binaries archive's