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

[djs55]

Summary

Add kit which runs VS Code inside the sandbox and forwards the display to the host using the --display experimental option.

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=1db5bff055d16d2fa23dc69576b3c736acde611b&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.

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.