docs(widgets): say the limit of a chosen folder's id and how to choose a remade folder again

docs/api.html

@@ -533,7 +533,7 @@ <h2 id="widget-dev-sessions">Widget dev sessions</h2>
   <tbody>
     <tr><td>POST</td><td><code>/widget-dev/sessions</code></td><td><code>{ root, conversationId?, widgetId? }</code></td><td>Starts watching <code>root</code>, an absolute path on the node. <code>201</code> with the session once its first build ran and was activated as far as the policy allows. With <code>conversationId</code>, the widget is placed there, pinned open, once a generation runs. Starting a folder that has a stopped session picks that session up again. Person-only.</td></tr>
     <tr><td>GET</td><td><code>/widget-dev/sessions</code></td><td>–</td><td><code>{ sessions: [...] }</code></td></tr>
-    <tr><td>GET</td><td><code>/widget-dev/sessions/{id}</code></td><td>–</td><td>One session: <code>latest</code> (newest good build), <code>running</code>, <code>activation</code> (<code>active</code>, <code>awaiting-approval</code> with <code>approvalId</code>, <code>refused</code> with <code>code</code> and <code>message</code>, or <code>none</code>), <code>lastBuild</code> (with <code>diagnostics</code> when it failed), <code>showingLastKnownGood</code>, <code>placed</code>, and for a stopped session <code>stopReason</code> (<code>requested</code>, <code>watch-failed</code>, <code>folder-gone</code>, <code>capacity</code> or <code>root-refused</code>). Reading changes nothing.</td></tr>
+    <tr><td>GET</td><td><code>/widget-dev/sessions/{id}</code></td><td>–</td><td>One session: <code>latest</code> (newest good build), <code>running</code>, <code>activation</code> (<code>active</code>, <code>awaiting-approval</code> with <code>approvalId</code>, <code>refused</code> with <code>code</code> and <code>message</code>, or <code>none</code>), <code>lastBuild</code> (with <code>diagnostics</code> when it failed), <code>showingLastKnownGood</code>, <code>placed</code>, and for a stopped session <code>stopReason</code> (<code>requested</code>, <code>watch-failed</code>, <code>folder-gone</code>, <code>capacity</code> or <code>root-refused</code>). <code>root-refused</code> means that, when the node started again, the folder was no longer one the session may watch: for example a session Clark started in a chosen folder that was deleted and made again while the node was stopped. What it ran keeps running, and the person's own start (<strong>Develop again</strong> on the <code>/develop</code> card) chooses the folder again. Reading changes nothing.</td></tr>
     <tr><td>DELETE</td><td><code>/widget-dev/sessions/{id}</code></td><td>–</td><td>Stops watching. The running generation stays installed and keeps rendering where it was placed.</td></tr>
     <tr><td>POST</td><td><code>/widget-dev/sessions/{id}/rebuild</code></td><td>–</td><td>Builds the folder as soon as no other build is running; while the folder is being made again, the build waits for it to come back. <code>409 SESSION_STOPPED</code> for a stopped session. Person-only.</td></tr>
     <tr><td>POST</td><td><code>/widget-dev/sessions/{id}/place</code></td><td><code>{ conversationId, widgetId? }</code></td><td>Places the running widget in a conversation. Person-only.</td></tr>
@@ -542,7 +542,7 @@ <h2 id="widget-dev-sessions">Widget dev sessions</h2>
 </table></div>
 <p>Starting, rebuilding and placing install code, so the WebSocket relay, <code>clarkcant api</code> and MCP refuse them with <code>403 PERSON_ONLY</code>. Forgetting a chosen folder is refused the same way: taking a choice back is yours, as making it is. Reading and stopping a session stay reachable everywhere. In the conversation, Clark's <code>develop_widget</code> tool (<code>start</code>, <code>choose</code>, <code>folders</code>, <code>status</code>, <code>rebuild</code>, <code>place</code>, <code>stop</code>) drives the same sessions; it starts, rebuilds or places only in a turn the person sent, never in one a machine surface, an automation or a paired node sent. <code>choose</code> and <code>folders</code> only show you the <code>develop</code> card (a folder to choose, or the folders you chose, each with <strong>Forget</strong>); neither starts nor forgets anything. <code>choose</code> offers a lasting choice, so it too runs only in a turn you sent; <code>folders</code> only narrows access and runs in any turn.</p>
 <ul>
-  <li><strong>Folders.</strong> <code>root</code> is resolved to its real path first. <code>400 ROOT_NOT_LOCAL</code> refuses a Windows network share or device path; <code>400 ROOT_IN_DATA_FOLDER</code> refuses the node's data folder, a folder inside it or one that holds it, except Clark's widget workspace <code>&lt;dataDir&gt;/widget-workspace</code>. A session you start on the route marks its folder as one you chose (<code>chosenByPerson</code> in the session view), but only when the path you gave is the folder itself as it resolves at that moment: a path through a link or junction starts the session it leads to without marking anything, so a link swapped in after the card was drawn grants nothing. The choice covers every folder inside it. A whole drive or your home folder itself is never marked: a session may run there, but Clark keeps no access. A chosen folder is kept as the real path it had when you started it, together with that folder's device and file id, so if that path later leads somewhere else (the folder was replaced by a link or junction, moved or removed), or holds another folder made there after yours went, the choice no longer counts; it is still listed, as not found, so you can forget it. It counts again only when that same folder is moved back. A choice kept by an earlier version has no id yet: it takes the id of the folder found at its path the first time one is, and is held to that folder from then on. A session Clark starts may watch that workspace, a folder you chose (or one inside it), or a folder inside a <code>workspace.roots</code> preference you recorded yourself; any other folder is <code>403 ROOT_NOT_OWNED</code>, nothing starts, and Clark's answer carries a host-drawn <code>develop</code> card offering the folder to you.</li>
+  <li><strong>Folders.</strong> <code>root</code> is resolved to its real path first. <code>400 ROOT_NOT_LOCAL</code> refuses a Windows network share or device path; <code>400 ROOT_IN_DATA_FOLDER</code> refuses the node's data folder, a folder inside it or one that holds it, except Clark's widget workspace <code>&lt;dataDir&gt;/widget-workspace</code>. A session you start on the route marks its folder as one you chose (<code>chosenByPerson</code> in the session view), but only when the path you gave is the folder itself as it resolves at that moment: a path through a link or junction starts the session it leads to without marking anything, so a link swapped in after the card was drawn grants nothing. The choice covers every folder inside it. A whole drive or your home folder itself is never marked: a session may run there, but Clark keeps no access. A chosen folder is kept as the real path it had when you started it, together with that folder's device and file id, so if that path later leads somewhere else (the folder was replaced by a link or junction, moved or removed), or holds another folder made there after yours went, the choice no longer counts; it is still listed, as not found, so you can forget it. It counts again when that same folder is moved back, and a new folder at its path is chosen when you start it yourself. A choice kept by an earlier version has no id yet: it takes the id of the folder found at its path the first time one is, and is held to that folder from then on. One limit: the id tells folders apart only while the filesystem does not give a later folder the same one. Windows (NTFS) gives a folder made again a new id, but on Linux (ext4 and similar) a folder deleted (not moved) and made again at once at the same path can get the deleted folder's id and then counts as the one you chose. A watched folder is held open on Linux and macOS, so this does not happen while a session watches it. A folder's birth time is not used as a second check: it is no finer than the filesystem's clock tick, and where it cannot be read Node reports the change time, which moves with every file added or removed. Forget a folder before deleting it if a folder made there later must not inherit the choice. A session Clark starts may watch that workspace, a folder you chose (or one inside it), or a folder inside a <code>workspace.roots</code> preference you recorded yourself; any other folder is <code>403 ROOT_NOT_OWNED</code>, nothing starts, and Clark's answer carries a host-drawn <code>develop</code> card offering the folder to you.</li>
   <li><strong>Choosing a folder.</strong> <code>/develop</code> and <code>/develop &lt;folder&gt;</code> (or asking Clark, which uses <code>develop_widget</code> <code>choose</code>) answer with the same <code>develop</code> command card. It names the folder the path resolves to when the card is drawn, and shows the path given when that differs; a press sends that canonical path, which is kept as your choice only if it is still the folder itself when pressed. A path that is not found, not absolute, or a network share or device gets no button, only a note saying why. Each row's action is <code>{ "kind": "develop-folder", "root"? }</code>, and the card starts nothing itself: a press in your own app calls <code>POST /widget-dev/sessions</code> as you, so no agent, widget or machine surface chooses a folder for itself. Without a <code>root</code> the desktop app opens the system folder dialog; where it cannot (a browser, a node on another machine, a dialog that does not open) the row asks for the path.</li>
   <li><strong>Forgetting a folder.</strong> <code>/develop forget</code> (or asking Clark which folders it may use) lists the folders you chose, each with a <strong>Forget</strong> button whose action is <code>{ "kind": "develop-folder-forget", "root" }</code>. A press calls <code>POST /widget-dev/chosen-folders/forget</code> as you. Forgetting does not stop a running session, and a folder inside another folder you chose stays reachable through that one; the answer says so.</li>
   <li><strong>Packages.</strong> Only <code>isolated-ui</code> and <code>declarative</code> facets run. A package with a service, tools or native facet fails to build with <code>FACET_LANE_UNSUPPORTED</code>. A package id that belongs to something else on the node is refused as <code>activation.state: "refused"</code> with <code>PACKAGE_LISTED</code>, <code>PACKAGE_IN_OTHER_SESSION</code> or <code>PACKAGE_INSTALLED_OTHERWISE</code>.</li>

docs/cli.html

@@ -108,7 +108,7 @@ <h2 id="widget-dev-sessions">Develop a widget in the conversation</h2>
 <p><code>clark widget dev</code> simulates a node. To see the widget on your node itself, ask Clark to develop one (“build me a timer widget”), or start a session on the <a href="api.html#widget-dev-sessions">widget dev session routes</a>. Your node watches the folder with the same build engine the dev host uses. Every change that reads as a package becomes a new build, named by the digest of its files, copied into the node's package cache and listed for this node alone, then installed through the ordinary install path. Nothing goes through npm, the Marketplace or a directory index, and nothing is published. A <code>node_modules</code> folder at the top is left out of each build; built output such as <code>dist</code> is kept.</p>
 <p>The widget appears in the conversation in the real widget frame, with the real sandbox, bridge, state and migrations. A new build reloads only the frame: the widget keeps its state, which goes through the package's own migrations when the version changes. Beside the frame, your node says which build is on screen and, when it is not the newest, why: the new build failed (with its problems listed), it waits for your answer in the inbox, or the policy refused it. “Showing the last successful build” appears exactly when that is what you see.</p>
 <ul>
-  <li><strong>Where.</strong> Clark develops widgets in its own widget workspace, <code>&lt;dataDir&gt;/widget-workspace</code>, where it scaffolds a new one. To have Clark work on a widget project you already have, choose its folder yourself: type <code>/develop</code> (or <code>/develop &lt;folder&gt;</code>, or ask Clark) and press <strong>Choose folder…</strong> in the card that answers. The desktop app opens your system's folder dialog; a browser, or a desktop app connected to a node on another machine, asks for the folder's full path on the node's machine and says why. If Clark wants to develop a folder you have not chosen, nothing starts, and the same card offers it to you with <strong>Develop this folder</strong>. The card names the folder the path really leads to, and says so when that differs from the path you gave; a path that is not found gets no button. A press keeps the folder as your choice only if the path is still that folder itself when you press, so a link put in its place meanwhile gains nothing. Only a message you sent can make Clark show a folder to choose. Once you start a folder, Clark may work in it, and in every folder inside it, without asking again, until you take that back: type <code>/develop forget</code> (or ask Clark which folders it may use) and press <strong>Forget</strong> beside the folder. Forgetting does not stop a running session, and a folder inside another folder you chose stays reachable through that one (the answer says so). A chosen folder that is moved away is listed as not found, so you can still forget it; it counts again only if that same folder is moved back, not when another folder is made at its path. A whole drive or your home folder can be developed for one session, but Clark never keeps access to it. A session you start yourself may watch any local folder, but never the node's own data folder or a network share.</li>
+  <li><strong>Where.</strong> Clark develops widgets in its own widget workspace, <code>&lt;dataDir&gt;/widget-workspace</code>, where it scaffolds a new one. To have Clark work on a widget project you already have, choose its folder yourself: type <code>/develop</code> (or <code>/develop &lt;folder&gt;</code>, or ask Clark) and press <strong>Choose folder…</strong> in the card that answers. The desktop app opens your system's folder dialog; a browser, or a desktop app connected to a node on another machine, asks for the folder's full path on the node's machine and says why. If Clark wants to develop a folder you have not chosen, nothing starts, and the same card offers it to you with <strong>Develop this folder</strong>. The card names the folder the path really leads to, and says so when that differs from the path you gave; a path that is not found gets no button. A press keeps the folder as your choice only if the path is still that folder itself when you press, so a link put in its place meanwhile gains nothing. Only a message you sent can make Clark show a folder to choose. Once you start a folder, Clark may work in it, and in every folder inside it, without asking again, until you take that back: type <code>/develop forget</code> (or ask Clark which folders it may use) and press <strong>Forget</strong> beside the folder. Forgetting does not stop a running session, and a folder inside another folder you chose stays reachable through that one (the answer says so). A chosen folder that is moved away is listed as not found, so you can still forget it; it counts again if that same folder is moved back, and a new folder at its path is chosen when you start developing it yourself. One limit: on Linux (ext4 and similar), a folder deleted (not moved) and made again at once at the same path can get the deleted folder's file id and then still count as the one you chose, so forget a folder before deleting it if a folder made there later must not inherit the choice. If a session Clark started stops after a restart because its folder is no longer one Clark may watch on its own (for example, it was deleted and made again), what it built keeps running; press <strong>Develop again</strong> on its row in the <code>/develop</code> card to choose the folder again. A whole drive or your home folder can be developed for one session, but Clark never keeps access to it. A session you start yourself may watch any local folder, but never the node's own data folder or a network share.</li>
   <li><strong>What.</strong> A session runs only widgets that stay in the frame and declarative data (<code>isolated-ui</code> and <code>declarative</code> facets). A package with a service, tools or a native part is refused with a problem saying so; install it the ordinary way.</li>
   <li><strong>Consent.</strong> Your execution policy decides each install as it decides any other. A session Clark started is Clark's own proposal, so guarded mode asks before its first install; a session you started is your request. When your mode asks, the first install is a question, and so is every build that changes what the package reaches: declared reach, resources, facet lanes, facets, permissions or requested capabilities. A build that changes only code or UI reuses your answer and runs at once. A mode that does not ask runs every build, and when a build reaches more than the one before it without anyone being asked, the conversation says what it added.</li>
   <li><strong>Limits.</strong> A node watches at most 8 folders at once. A folder over 5,000 files or 64 MiB, or one holding a link that points outside it, is refused with what to change.</li>