feat: bind a named Claude profile as the container's configuration, so it can refresh

[JSmithRobotics]

--claude-profile forwards a profile's access token by value
(clients::claude::resolve_token → claude::Token). That token cannot refresh:
there is nothing to refresh it with and nowhere to persist the result. A
workspace that outlives the expiry has a dead credential until some later launch
replaces it, and the session discovers that mid-run.

This binds the profile directory instead, so Claude Code gets the same files it
has on the host and refreshes exactly as it does there, with the refresh landing
back in the profile.

Why this is worth reading now rather than as a downstream preference

9a47af9 ("configure persistent Herdr workspace environments from dl") routes
straight into the forwarding path:

// flows/herdr_environment.rs
/// The name to pass on as `--claude-profile`, for the two arms that name one.
pub fn profile_name(&self) -> Option<&str> {
    Self::Profile(name) => Some(name.as_str()),
    Self::ServerDefault => Some(DEFAULT_PROFILE),

So the feature whose entire purpose is persistent panes authenticates them with
a credential that cannot outlive its expiry. The longer a herdr workspace does
its job, the likelier it is to be holding a dead token. That is upstream's bug,
not the fork's, and it arrived after the branch point.

What it binds, and what it does not

The profile directory carries the credential, and also CLAUDE.md, agents/,
skills/, hooks/, commands/. Not .mcp.json: that lives at a project root
rather than under CLAUDE_CONFIG_DIR, so binding a profile never touches it.

ClaudeProfileMount sits beside PixiCache and does the same job by the same
means: bind a host directory, point the container at it, via --mount type=bind,... and --workspace-env CLAUDE_CONFIG_DIR=....

The two flags land together or not at all. up_args composes both only when the
call actually creates or rebuilds the container, because a --mount applies only
then while --workspace-env would otherwise be re-applied alone on every up
and silently repoint CLAUDE_CONFIG_DIR at an empty directory.

The trade-off, stated rather than buried

This hands the container a refresh token. The existing design deliberately does
not: forwarding an access token by value means a compromised container holds
something that expires on its own. A bind mount means it holds something that
does not, and can mint more.

That is a real cost and I am not going to argue it away. The exchange is a
profile that survives the container, for a credential the container could abuse
for longer. Where a session is short, forwarding is the better trade and should
stay the default. Where a session is long-lived — which is precisely what
9a47af9 builds — forwarding does not work at all, and the choice is not between
two security postures but between a working credential and a dead one.

It is opt-in per launch and changes nothing for a launch that does not ask.

Provenance, and one interaction worth knowing

These five commits have run in a fork since 2026-09 against long-lived agent
sessions; this is a port onto 0.57.0, where four of the five applied with no
conflict.

The interaction: #651 reports dl announcing a --mount that devpod silently
dropped, measured through this mount. The same --mount plus --workspace-env
pair carries the pixi cache today, so that defect is not introduced here. But it
does mean a profile can be reported bound and not be, and I would rather that
were known while reviewing this than discovered afterwards.

Checks

cargo build --workspace, cargo clippy --locked --all-targets -- -D warnings
and cargo fmt --check are clean on the port. I have not run
cargo test --workspace or the Python suite: both create real devpod containers,
and the host I ported on is running workspaces I am not willing to disturb. CI is
the right place for that, and I would rather say so than let green checks here
imply more than they cover.

The public-API snapshots almost certainly need regenerating, and I could not
do it. The mount adds public types, so those files must change; the ones here
came across with the port. Regenerating them correctly needs the pinned nightly
scripts/public-api-snapshots.sh --print-nightly names, and the host I ported on
has no rustup. CI will print the authoritative diff -- I would rather flag that
than have a reviewer discover it.

https://claude.ai/code/session_01AdSFnBdxie6TosHVmjLY28

[sourcery-ai]

Sorry @JSmithRobotics, your pull request is larger than the review limit of 150,000 diff characters

[codecov]

Codecov Report

❌ Patch coverage is 99.64093% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.59%. Comparing base (11d160d) to head (0eeede4).

Files with missing lines	Patch %	Lines
rust/dl/src/render.rs	99.06%	2 Missing ⚠️

Additional details and impacted files

Flag	Coverage Δ
python	42.98% <ø> (ø)
rust	94.81% <99.64%> (+0.15%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
shipped code (rust)	94.81% <99.64%> (+0.15%)	⬆️
harness and tooling (python)	42.98% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.