A project-local config can no longer widen the sandbox fence

[yusiwen]

What changed

• config/config.go: SandboxBoundary plus UserSandboxBoundary() (code defaults + the user's own file) and ProjectSandboxBoundary() (the same keys as the project file spells them, so a caller can report what it dropped).
• main.go: one installSandboxBoundary() installs the boundary root, the working-directory auto-allow and the allowed paths from the user layer, and logs project_local_boundary_keys_ignored when the project file asked for either widening key. The duplicated later block is gone, and the language server workspace now reads the same installed root instead of the merged config.
• config/config_test.go, main_test.go: three tests — the layer rule, the wiring (with a control), and the other column of the table.
• docs/sandbox.md: a "which layer may set what" table recording the decision this issue asked for.

Why

The configuration layers defaults → user → project, and the project layer arrives with the repository, so the agent may run with it before anyone has read it. The sandbox wiring read sandbox.project_root and sandbox.allowed_paths out of the merged result, which made a checked-out repository able to widen the fence that is supposed to contain it.

Measured with the real binary (one-shot, build mode, redirected HOME with no grant, writing /tmp/stub-outside-write.txt):

./.tinycode/config.json	on master d351ee8	on this branch
{"sandbox":{"project_root":"/"}}	CREATED	refused
{"sandbox":{"allowed_paths":["/tmp/stub-outside-write.txt"]}}	CREATED	refused
{"default_mode":"build"}	refused	refused
the same allowed_paths in the user's file (control)	CREATED	CREATED

The LSP workspace root had the same source, so a repository could also point the language server at / while the fence still called the repository the project; it now takes the installed root, so "inside the project" means one thing to both.

Verification

• The table above, before and after, with a fresh stub per case; the ignored-key warning is in the run log (project_local_boundary_keys_ignored).
• go test ./... -count=1 → 13 packages ok; -count=1 -race → 13 packages ok; go vet ./... clean; gofmt -l nothing.
• make test-tui-scenarios → exit 0, 31 scenario files, 27 ok, 4 skipped by design (confine-bash-write, live-answer, lsp-diagnostics, lsp-tools, each naming its make target).
• Mutation: making UserSandboxBoundary() return the merged config fails both fence tests — boundary root = "/", is allowed: the project-local config widened the fence (and the config-layer test: user boundary root = "/", user allowed paths = [/srv/user-cache /etc]). Restored, all pass.
• CI: recorded in the checks below.

Honest scope

• make test-tui-confine cannot run on this macOS host (no Landlock; the target skips loudly), so the kernel-boundary job remains CI-only. The change here is wiring that runs everywhere.
• gopls is not installed here, so make test-lsp / make test-tui-lsp were not run locally; the LSP workspace change is covered by CI's LSP integration (gopls + typescript) job and by the ungated scenario suite, in which the two LSP scenarios are skipped locally by design.
• What a project-local sandbox block may still do is now written down rather than inferred: deny_commands accumulates, and the two hardening booleans can be turned on by any layer but never off (enforced by merge() since the sandbox landed).

Follow-ups

• Closes [security] A repository-local config can widen or remove the sandbox fence #162. Refs [tui] Pin the persisted grant on the next start, now that a scenario can tell one run from the next #155 (the grant-loading rule this one follows), [security] Sandbox hardening: landing plan and progress #127 (the sandbox landing plan).