Fix clipboard OSC 52 write and mason registry access in the sandbox

- clipboard-copy: nvim's job-spawned clipboard provider process doesn't get
  its own controlling terminal, so /dev/tty (ENXIO) fails. Resolve the real
  tty from the parent (nvim)'s recorded tty via ps instead.
- entrypoint.sh: chown the allocated pty to node before dropping privileges.
  A normal login/ssh session always does this; this entrypoint skipped it,
  leaving the tty root-owned so node couldn't write to it directly even
  after resolving the right path.
- init-firewall.sh/README: allow release-assets.githubusercontent.com.
  GitHub release assets (e.g. mason-registry's own index) redirect here,
  a separate CDN from github.com's published IP ranges - without it mason
  can't even look up a package's install spec, regardless of PyPI access.

All three verified against a rebuilt image: OSC 52 write reaches the real
pty with no error, and mason's registry refresh succeeds through the
firewall.

bin/clipboard-copy

@@ -18,5 +18,15 @@ elif [ -n "$DISPLAY" ] && command -v xclip >/dev/null 2>&1; then
     setsid -f xclip -selection clipboard
 else
     data=$(base64 | tr -d '\n')
-    printf '\033]52;c;%s\a' "$data" > /dev/tty
+    # /dev/tty needs this process's own session to have a controlling
+    # terminal, but a job spawned by nvim's clipboard provider doesn't get
+    # one (nvim's job-spawning doesn't establish a ctty for children).
+    # Resolve the real terminal from the parent's (nvim's) recorded tty
+    # instead, which doesn't depend on this process having its own ctty.
+    real_tty="/dev/$(ps -o tty= -p "$PPID" 2>/dev/null | tr -d ' ')"
+    if [ -w "$real_tty" ]; then
+        printf '\033]52;c;%s\a' "$data" > "$real_tty"
+    else
+        printf '\033]52;c;%s\a' "$data" > /dev/tty
+    fi
 fi

docker/claude-sandbox/README.md

@@ -82,8 +82,10 @@ On start, the container runs an allowlist-only `iptables`/`ipset` firewall
 (`init-firewall.sh`), matching the reference dev container. Allowed by
 default: DNS resolution via Docker's embedded resolver (loopback only, so
 never leaves the container), the Docker host itself (not its whole subnet),
-GitHub's published IP ranges, `registry.npmjs.org`, `pypi.org` and
-`files.pythonhosted.org` (mason's Python-based LSP tools - `ruff`,
+GitHub's published IP ranges, `release-assets.githubusercontent.com`
+(GitHub release assets - e.g. mason's own registry index - redirect here,
+a separate CDN from github.com's own IPs), `registry.npmjs.org`, `pypi.org`
+and `files.pythonhosted.org` (mason's Python-based LSP tools - `ruff`,
 `basedpyright`, `debugpy` - install via pip), `api.anthropic.com`, and
 whatever hosts `GITEA_SSH_HOST`/`GITEA_API` resolve to — that last group
 isn't port-restricted, so git-over-ssh to GitHub/Gitea works without a

docker/claude-sandbox/entrypoint.sh

@@ -14,6 +14,15 @@ if [ "${ENABLE_FIREWALL:-1}" = "1" ]; then
     EXTRA_ALLOWED_DOMAINS="${extra_domains}" /usr/local/bin/init-firewall.sh
 fi
 
+# A normal login/ssh session always chowns the allocated pty to the logging
+# in user; this container's entrypoint skips that (there's no login/sshd
+# involved), leaving the tty root-owned. nvim's clipboard fallback needs to
+# write to it directly as node, so fix the ownership up here, before
+# dropping privileges.
+if [ -t 1 ]; then
+    chown node "$(tty)" 2>/dev/null || true
+fi
+
 # Drop root -> node for the actual session; node has no sudo/setuid path
 # back to root after this, so it can't re-run init-firewall.sh itself to
 # widen the allowlist mid-session.

docker/claude-sandbox/init-firewall.sh

@@ -65,7 +65,8 @@ for domain in \
     "api.anthropic.com" \
     "gitlab.com" \
     "pypi.org" \
-    "files.pythonhosted.org"; do
+    "files.pythonhosted.org" \
+    "release-assets.githubusercontent.com"; do
     echo "Resolving $domain..."
     ips=$(dig +noall +answer A "$domain" | awk '$4 == "A" {print $5}')
     if [ -z "$ips" ]; then