docs(desktop): record why access-denied reserving is not a double reservation

Review read `WorkspaceHostProvider` as rendering the denied page inside the chrome. It is
the other way round: the provider wraps `<WorkspaceChrome>` in the layout, and its 403
branch returns the denied page instead of its children, so the chrome never mounts. The
server-side early return does the same thing higher up.

Both paths therefore bypass the chrome and the page's own reservation is the only one.
Recording that next to the entry, since the file lives under a workspace path where
inherited coverage is the norm and the reading is an easy one to repeat.

Author: waleedlatif1

apps/sim/app/_shell/desktop-title-bar-surfaces.test.ts

@@ -270,6 +270,10 @@ const isExempt = (file: string) =>
  * tree, so its inherited coverage is real.
  */
 const SELF_RESERVE_REQUIRED = new Set([
+  // Both of its render paths bypass the chrome, so its own reservation is the only one:
+  // `layout.tsx` returns it before reaching `<WorkspaceChrome>`, and
+  // `WorkspaceHostProvider` — an ancestor of the chrome, not a descendant — returns it
+  // instead of its children on a client-side 403. Neither is a double reservation.
   'app/workspace/[workspaceId]/components/workspace-access-denied.tsx',
 ])