Resolve the last component of a write, not just the directory

[beardthelion]

Closes #100.

resolvePath resolves the directory a write lands in and returns the lexical target, so a symlink sitting at the last component is followed by writeFile and the bytes land wherever it points, as root. The module documents three confinement layers and names the symlink layer as the one people miss; on the write path it covers everything except the name being written to.

What it does

Resolves the last component too, when it is a link:

• lstat the target. Only a symlink is treated specially, so an ordinary file or a name that does not exist yet takes the path it took before.
• A link that resolves is checked against the root with the same assertInside as every other layer.
• A dangling link is refused rather than resolved. It points at a file that does not exist, so there is nothing to compare, and writing through one creates the file it names.

Links pointing back inside still work, for writes as well as reads. The guard has to confine rather than forbid: refusing every link would pass every refusal test in the suite and break what links are legitimately for.

Append takes the same resolved path and is covered by the same check.

Verification

Four new cases in agent-computer/tests/workspace.test.ts, against real inodes in a temporary directory, because a symlink test with a fake filesystem tests the fake. Three fail before the change and pass after:

• a write through a link at the file itself, asserting the outside file is untouched rather than only that the call refused
• the same through append
• a write through a dangling link, asserting no file is created outside

The fourth extends the existing "points back INSIDE still works" case to write as well as read, which is the assertion that would catch a fix that simply forbade links.

153 tests pass in agent-computer. bunx tsc --noEmit and bunx biome check clean on the changed files. Whole-tree bun test failure set is identical to main (the integration tests wanting a Postgres).

Note on the shared arrangement

Without COMPUTER_SUPERVISOR_URL every Bot shares one container and one /workspace, so this is also the path by which one Bot plants a link and another writes through it. That arrangement has other reasons not to be used for mutually untrusted Bots, and shell.ts says so already; this closes the file boundary either way.

[beardthelion]

Duplicate of #74, which came first. Closing in favour of it: #74 also resolves a link pointing at a file that does not exist yet, which this one refuses outright, and it handles a workspace sitting behind a symlinked root.