feat: add Linux server operational delivery assets

docs/implementation-plan.v1.md

@@ -11,12 +11,10 @@ binaries:
   spool, and reconnect/reconciliation owner.
 - `rvc`: local CLI over the server's Unix-domain gRPC socket.
 
-The first supported client target is Windows connecting to a Linux server;
-Linux client support remains part of complete v1 but is explicitly deferred
-from the current implementation effort. Implement the Linux server and native
-Windows client first; do not begin Unix-like client code now. Build shared
-client runtime code behind OS interfaces without prematurely implementing the
-Unix supervisor. Windows v1 requires Windows 10 or newer, or Windows Server 2016
+The v1 product boundary is a Linux server and a native Windows client. A
+Unix-like client is outside v1 and must not be started as part of this plan.
+Build shared client runtime code behind OS interfaces without prematurely
+implementing the Unix supervisor. Windows v1 requires Windows 10 or newer, or Windows Server 2016
 or newer. Desktop Experience is required only for the tray and active-session
 command contexts; the service and Session 0 execution contexts support headless
 Server Core.
@@ -2326,7 +2324,7 @@ version. Assert no Task Scheduler object is created or required.
 loss/restart, execute up to capacity at most once, preserve/replay bounded
 history, manage complete Job trees, and satisfy tray/elevation/autostart behavior
 on Windows CI, including all execution-hierarchy rows. Reaching this gate does
-not automatically start the deferred Unix-client work; that requires an explicit
+not automatically start future post-v1 Unix-client work; that requires an explicit
 later implementation decision.
 
 ## 8. End-to-end agent protocol (Phase 5)
@@ -2383,7 +2381,7 @@ the visible CLI result. Include these cross-cutting cases:
 server demonstrates a complete background command, history/follow behavior,
 stdin interaction, signal, reconnect, and restart recovery through nginx WSS.
 This is the first supported-client milestone. It satisfies a prerequisite for
-the deferred Linux supervisor work but does not automatically authorize it.
+future Linux-supervisor work but does not automatically authorize it.
 
 ## 9. Server control plane and `rvc` (Phase 6)
 
@@ -2534,14 +2532,14 @@ stack; the Unix socket has mode `0600`; JSON-RPC behavior matches gRPC unary
 semantics and is off unless explicitly enabled; the control integration suite
 can be interrupted, resumed, and reset through the shared run ID.
 
-## 10. Deferred Linux client implementation (Phase 7; still required for full v1)
+## 10. Future Unix-like client work (outside v1)
 
-This phase is design-only in the current effort. Do not implement it now. Retain
-these tasks so the later Unix-client work completes the already defined v1
-contract without weakening the shipped Windows behavior.
+This work is outside the v1 product boundary. Do not implement it now. Retain
+these tasks as the starting point for a later Unix-client scope without
+weakening the shipped Windows behavior.
 
-Begin this phase only after both an explicit later implementation decision and
-the Windows Phase 4/5 release gates. Keep Unix code in platform-specific files/
+Begin this work only after an explicit later implementation decision and the
+Windows release gates. Keep Unix code in platform-specific files/
 build tags and reuse the proven runtime/store/protocol contracts without
 changing their wire semantics to suit Linux.
 
@@ -2602,9 +2600,9 @@ reconnect/replay, truncation, scripts, tombstones, queue limits, `/proc`
 absence, profile failure, and shutdown interruption. Add explicit tests for
 pidfd/`clone3` availability fallbacks and deliberate `setsid` escape behavior.
 
-**Exit criteria:** the Linux client passes the same protocol/durability suite as
-Windows, plus cgroup/process-group tests, without weakening the already shipped
-Windows behavior or changing the v1 wire contract.
+**Future exit criteria:** the Linux client passes the same protocol/durability
+suite as Windows, plus cgroup/process-group tests, without weakening the
+already shipped Windows behavior or changing the established wire contract.
 
 ## 11. Reliability, observability, and operational delivery (Phase 8)
 
@@ -2691,9 +2689,8 @@ The currently authorized merge order is deliberately vertical:
 8. The Windows-applicable Phase 8 operational, packaging, stress, and release
    gates needed for the Linux-server/Windows-client milestone.
 
-Stop there for the current effort. When Unix-client implementation is explicitly
-started later, continue with Phase 7 (Linux supervisor/cgroup and client parity),
-then the remaining Phase 8 Unix operational/release gates to complete v1.
+Stop there for v1. Any Unix-client implementation is a separately authorized
+post-v1 effort and does not change this milestone's completion criteria.
 
 Do not merge a later vertical slice by stubbing a durability/safety invariant.
 For example: foreground mode may wait on a durable background command, but must
@@ -2701,12 +2698,9 @@ not bypass persistence; client output may be truncated under the documented
 caps, but must never block a child pipe; and a reconnection may replay work,
 but may never re-execute an already accepted UUID.
 
-The current Windows-client milestone is releasable only after Phases 0–6 plus its
-applicable Phase 8 packaging/security gates pass on native Windows and a clean
-Linux server environment. Windows support cannot be marked optional or replaced
-by cross-compilation-only checks. Stop the current implementation effort at that
-milestone; Phase 7 remains deferred until explicitly started later. Full v1 is
-ready only after that later Linux client also passes the common protocol/
-durability suite and Linux-specific cgroup/process tests. Every release must
+The Linux-server/Windows-client v1 milestone is releasable only after Phases 0–6
+plus its applicable Phase 8 packaging/security gates pass on native Windows and
+a clean Linux server environment. Windows support cannot be marked optional or
+replaced by cross-compilation-only checks. Every release must
 conspicuously document self-reported identity, the elevated Windows execution
 authority, and unauthenticated optional JSON-RPC.