docs(sync): correct the ownership precedence the fix inverted

Review found the owning documentation still describing the behaviour this
branch replaced, in one case stacked directly above the new docstring saying
the opposite. Holding a session proves containment, not ownership, so every
text that called store membership the authoritative mapping was actively
misleading for the module whose wrong answer misroutes every send.

Corrected in the module docstring, the resolution module's precedence
description, the sync-refs helper it points at, and the sync DOCUMENTATION.md
table and rules.

The debug report built its authoritative value membership-first, so for exactly
the scenario this branch fixes it reported the parent directory and could raise
a source-disagreement alert while routing was in fact correct. It now uses the
same record-first order as the resolver.

The CLI timeout comment claimed the wait and provisioning windows were additive
while the code took the larger of the two. The server provisions the worktree
inside session creation, before it waits for the session to go idle, so they do
run in sequence: the windows are now summed and the tests pin both cases.

packages/web/bin/lib/cli-control.js

@@ -28,9 +28,10 @@ export const resolveControlTimeoutMs = (input, options) => {
   }
   const waitSeconds = Number(input?.timeout) > 0 ? Number(input.timeout) : DEFAULT_WAIT_TIMEOUT_SECONDS;
   const waitTimeoutMs = (waitSeconds * 1000) + WAIT_HTTP_TIMEOUT_BUFFER_MS;
-  // Waiting for the session and provisioning its worktree are additive, so the
-  // window must cover whichever is longer rather than only the wait.
-  return provisionsWorktree ? Math.max(waitTimeoutMs, WORKTREE_PROVISION_TIMEOUT_MS) : waitTimeoutMs;
+  // The server provisions the worktree inside session creation, before it
+  // starts waiting for the session to go idle, so the two windows run in
+  // sequence rather than overlapping. The client window has to cover both.
+  return provisionsWorktree ? waitTimeoutMs + WORKTREE_PROVISION_TIMEOUT_MS : waitTimeoutMs;
 };
 
 export const requestControlAction = async (port, action, input, options = {}) => {

packages/web/bin/lib/cli-control.test.js

@@ -28,11 +28,10 @@ describe('resolveControlTimeoutMs', () => {
     expect(resolveControlTimeoutMs({ worktree: '   ' }, {})).toBeUndefined();
   });
 
-  it('covers worktree provisioning even when the wait window is shorter', () => {
-    expect(resolveControlTimeoutMs({ wait: true, timeout: 30, worktree: 'feature' }, {})).toBe(120_000);
-  });
-
-  it('keeps a longer wait window when it outlasts worktree provisioning', () => {
-    expect(resolveControlTimeoutMs({ wait: true, worktree: 'feature' }, {})).toBe(630_000);
+  it('covers provisioning and waiting in sequence when both are requested', () => {
+    // The server creates the worktree before it begins waiting for the session,
+    // so the client window must span both rather than the longer of the two.
+    expect(resolveControlTimeoutMs({ wait: true, timeout: 30, worktree: 'feature' }, {})).toBe(180_000);
+    expect(resolveControlTimeoutMs({ wait: true, worktree: 'feature' }, {})).toBe(750_000);
   });
 });