ci: stop mounting /etc/ssl/certs into the Nix sandbox

[fxrdhan]

Summary

Since #159 turned the Nix sandbox on, no fixed-output derivation can start in CI. That includes every crate download:

error: creating regular file "/nix/store/…-download-base64-0.23.1.drv.chroot/root/etc/ssl/certs/ca-certificates.crt": File exists

How it happens:

• Nix mounts ssl-cert-file at /etc/ssl/certs/ca-certificates.crt for each fixed-output derivation.
• extra-sandbox-paths = /etc/ssl/certs mounts the host directory first. That directory already holds the file.
• Nix creates the mount point with O_CREAT | O_EXCL, so that step fails.

Why no pull request caught it:

• Every crate download they needed came from Cachix.
• build(deps): Automatic dependency updates for 2026-10-06 #164, the dependency bump, is the first to need new ones, and its Nix Flake Validation fails at the first of them (run).
• The Nix Cold Build Canary builds every crate download without Cachix. Its last green run, on Oct 5 at 05:25 UTC, predates ci: shorten the CI gate's longest paths, and run the generated trycmd suites again #159 and ran unsandboxed. Monday's scheduled run would fail the same way.
• The extra sandbox path came in with ci: pass system SSL certificate paths to nix flake check #82, while the sandbox was off and the setting did nothing.

This drops it from ci.yml and nix-canary.yml. The crate downloads still get the CA bundle through ssl-cert-file, and nothing else in the sandbox has a network to need one. No test or trycmd case reads /etc/ssl.

Type of Change

• 🐛 Bug fix (non-breaking change fixing an issue)
• ✨ New feature (non-breaking change adding functionality)
• ⚡ Performance improvement
• ♻️ Code refactor / clean-up
• 💥 Breaking change (fix or feature that would cause existing functionality to change)
• 📝 Documentation / Man pages / Completions
• 🔧 Build / CI / Dependencies

Related Issues & Upstream References

• Resolves: the red Nix Flake Validation on build(deps): Automatic dependency updates for 2026-10-06 #164
• Upstream: n/a

How Has This Been Tested?

• Testing commands executed:
  • nix fmt (no changes), and actionlint on both workflows.
  • The failing run's derivation path, re-evaluated locally from build(deps): Automatic dependency updates for 2026-10-06 #164's flake.lock, is identical to CI's. Its only difference from the crate downloads the old canary built is the crate's hash.
  • The error message comes from Nix's mount code, which creates a mount point for each file it mounts with O_EXCL.
  • Nix Cold Build Canary dispatched on this branch (run): passed. It built 831 crate downloads sandboxed, without Cachix, and none failed with File exists.
  • build(deps): Automatic dependency updates for 2026-10-06 #164's two commits plus this one, on a scratch branch since deleted, with CI dispatched (run): every job passed. The Nix job built 111 crate downloads, including the download-base64-0.23.1 that failed on build(deps): Automatic dependency updates for 2026-10-06 #164.
• Platforms verified: Linux (the Nix jobs). This pull request's own Nix job takes its crate downloads from Cachix, so it does not exercise the fix; the two runs above do.

Contributor Checklist

• Base branch is set to dev (unless this is a release PR targeting main)
• My commits follow Conventional Commits format
• Tests covering the changes have been added/updated
• cargo clippy --all-targets passes with no warnings
• cargo nextest run (or cargo test) passes
• cargo fmt --check / nix fmt passes
• License headers (SPDX / REUSE) are properly preserved/added

🤖 Generated with Claude Code