feat(kits): add experimental vscode mixin using --display

[djs55]

Have you ever worried about running complex GUI applications on your host, especially apps which have sophisticated extension systems with correspondingly sophisticated supply chains? It's rational to worry; even the most vigilant users have been hacked via poisoned VS Code extensions.

Instead of running VS Code natively on your app, run it safely inside your Docker Sandbox instead.

The Linux version of VS Code runs in the microVM sandbox with all the governance applied, while the windows are transparently forwarded to the host. The green border is a reminder that the window is from inside the sandbox, a homage to Qubes OS

Spec choices worth flagging for review

My first kit, so it's hard to tell!

Origin

It's a simple wrapper of Linux VS Code. Previously VS Code always ran on the host and could connect into the sandbox. This kit colocates VS Code in the sandbox.

Test plan

For manual testing with sbx 0.39+:

sbx settings set platform.allowExperimentalFeatures true
sbx settings set feature.sandbox-display true
sbx settings set kit.allowedSources '["docker.io/","github.com/djs55/"]'

sbx run claude \
    --display \
    --kit "git+https://github.com/djs55/sbx-kits-contrib.git#ref=92469534d88a9bf55b55da93bc8e8bed2dd5cebd&dir=vscode" \
    ~/my-project

CI runs kit validate and the TCK on every PR. CI does not run e2e on
fork PRs (Docker Hub secrets aren't exposed there), so the e2e step below is
required from your side before requesting review.

• sbx kit validate ./<kit>/ passes
• ./scripts/test-kit.sh <kit> passes (the TCK)
• ./scripts/test-kit-e2e.sh <kit> passes. The script applies the same
  deny-all baseline CI uses and scopes everything to its own daemon
  (--app-name sbx-kits-contrib-tck), so my main sbx state is untouched.
  Every entry I added to network.allowedDomains came from
  sbx --app-name sbx-kits-contrib-tck policy log <tck-e2e-…>, not a guess.
• Manual smoke: sbx run --kit ./<kit>/ <agent> and verified the kit's
  binary / files / env are inside the running container.

All three re-verified at 94e2af7, after the apt fix in that commit — the
earlier e2e tick predated it and had gone stale. test-kit-e2e.sh vscode
passes under deny-all (real sbx create on claude-code-docker, install
hook OK in 38.1s, files / tmpfs / agentContext subtests PASS), and the manual
smoke confirmed code 1.138.0 installed, dbus-run-session present,
/run/display/wayland-0 live, and VS Code running with a GPU process on
--ozone-platform=wayland with the workspace open.

One-time setup if you haven't run e2e on this machine before:
sbx --app-name sbx-kits-contrib-tck login.

See CONTRIBUTING.md → Verifying locally
and README → Declare every domain your kit needs
for the cross-arch domain gotchas (archive.ubuntu.com,
security.ubuntu.com, ports.ubuntu.com) and the package-manager refresh trap.