fix(agent-presets,connection): reclaim a deleted default, unpin a fence beside an open gate

Deleting the preset a user default names left the setting pointed at an id
nothing will ever supply again, and every session created without an explicit
pick then failed to start — the delete dialog called it 'new sessions cannot
select it', which understates a hard creation error. `remove` now clears the
user layer when it named the preset just deleted, exposing the deployment's own
default underneath. Storing a default that does not exist YET stays deliberate:
the roster is a live directory, so a name absent now may exist by the time a
session asks, and `resolve` still reports that case.

`agentPreset.select` also leaves the loopback set. It was pinned as a real
escalation — one preset mounts the toolset that edits the live runtime — but
`session.create` already takes an `agentPreset`, so pinning only the switch left
the same capability one method over. The deeper reason is that the capability is
not the preset's to grant: the deployment's own default already carries `bash`
and the filesystem tools, so any caller that may start a session at all can
already run commands as this process. `read`/`write`/`remove` stay pinned on
their own footing — those touch files, not sessions.

.claude/launch.json

@@ -0,0 +1,19 @@
+{
+  "version": "0.0.1",
+  "configurations": [
+    {
+      "name": "dsh-web",
+      "runtimeExecutable": "env",
+      "runtimeArgs": [
+        "DSH_HOME=/Users/jyc/projects/agentProjects/deepseek-harness/.claude/worktrees/tool-call-side-effects-fix-680343/tmp/dsh_home",
+        "DSH_TELEMETRY_DISABLED=1",
+        "node",
+        "apps/cli/lib/bin.js",
+        "web",
+        "--port",
+        "3080"
+      ],
+      "port": 3080
+    }
+  ]
+}