feat: allow repos to inject customizations into the runtime

[perezd]

Codetainer's security model starts with sane and tight defaults, especially for a Bun/TypeScript-centric project. However, not every project will be that shape. Ideally, if a REPO_URL is specified, there should be a special folder (eg, .codetainer) that is allowed to contain configuration files that can be read by the container at boot time (post clone) to augment the VM environment to better support the needs of the project.

Some examples that come to mind:

• add custom allowlisted domains.
• augment the approval/rules.conf with additional project-specific rules. (with some concept of precedence)
• add additional Claude Code marketplaces & plugins.
• add arbitrary bash scripts that could install specific system dependencies as needed.

There are obvious security implications to consider when allowing this. However, these files are version-controlled and under the discretion of the project owner. While these may void the security warranties we've established, the value of customization is worth it.

It would be useful for Codetainer to have a built-in skill for managing this folder for a repo it's managing. That way, these edits could be introduced as a PR, and a simple reboot can update how the VM operates for the project.

[limbibot]

Note: Scoped registry auth should be addressed here

While investigating #32 (.npmrc credential exposure), we explored replacing .npmrc with bunfig.toml for GitHub Packages auth (@org scoped registries). bunfig.toml supports env var interpolation (e.g., token = "$GH_PAT"), which would avoid writing plaintext tokens to disk.

However, GH_PAT is intentionally excluded from the claude user's environment (see start-claude.sh sudo whitelist), so Bun can't resolve $GH_PAT at runtime. The fix for #32 will simply remove the .npmrc generation entirely to eliminate the exposure.

When .codetainer customization lands, it should include a mechanism for projects to declare scoped registries (e.g., a bunfig.toml template) along with a secure way to flow registry credentials to the claude user — without re-exposing GH_PAT in the process environment or on disk in plaintext.