Let the user pick a persona/expertise for the agent per session

[ukanga]

Use case

I keep a small library of system prompts — rust-developer.md,
security-reviewer.md, sre.md. Different worktrees need different ones. I
don't want to edit .wt.toml every time I switch personas, and I don't want
one repo-wide persona baked into config. Bonus: my agent (Claude Code,
opencode, etc.) already auto-loads project files like CLAUDE.md or
.claude/agents/... — if wt could write the persona straight there, my
agent_cmd doesn't need any extra wiring.

Outcome

A user can specify a system prompt at session creation time, separate from
the task prompt (#14). The agent in that session starts with that persona
applied. The two prompts are independently optional — supply one, both, or
neither.

The persona content lands somewhere the agent can actually read it. Two
integration shapes are valid endpoints; the implementer picks one (or supports
both via configuration):

• Env-var route: wt writes the persona to a wt-owned file and exposes a path
  env var; user wires it into agent_cmd via shell substitution. Simplest to
  ship; pushes a bit of agent_cmd complexity onto the user.
• Native-path route: wt writes the persona to an agent-native file like
  CLAUDE.md or .claude/agents/wt.md; the agent picks it up automatically.
  Cleaner agent_cmd; needs collision handling.

If both routes are supported, the destination is a configuration choice (e.g. a
system_prompt_path field) defaulting to the wt-owned location so existing
setups don't change.

Why now

System prompt and task prompt are semantically different — how to behave vs.
what to do — and most agents take them through different CLI surfaces.
Per-session personas remove the friction of editing config to switch hats per
worktree.

Acceptance criteria

• A user can set just a persona, just a task, or both, on wt session add.
• When both are set, the agent receives both at launch.
• Personas of arbitrary length and content (multi-line markdown, code
  fences, etc.) round-trip intact.
• The persona reaches the agent in a way that doesn't require the user to
  invent fragile shell escaping themselves.
• If the chosen approach can clobber a pre-existing file in the worktree
  (e.g. an existing CLAUDE.md), wt fails fast with a clear message naming
  the path — never silently overwrites.
• Paths that escape the worktree (absolute paths, .. segments) are
  rejected, if the destination is configurable.
• Documentation explains the persona/task distinction and walks through
  whichever routes are supported, with worked examples for at least Claude
  Code and opencode.

Design notes for the implementer

• The minimal version locks the persona destination to a wt-owned file (env-var
  route only). Ships the use case but leaves users with shell-substitution in
  agent_cmd.
• The richer version makes the destination configurable, supporting the
  native-path route. The env-var route is still available for users who don't
  want files showing up at agent-native paths. Adds: collision detection
  (refuse-if-exists), path validation, two doc examples.
• Refuse-if-exists is deliberately preferred over append-with-markers +
  restore-on-rm. Markers create state to track and recover after crashes,
  manual edits, and partial removals; a clear up-front error is easier to
  reason about for v1.

Out of scope

• Append-with-markers / restore-on-rm.
• A "persona library" config field naming a default persona to apply across
  sessions.
• Cleaning up the persona file after wt session rm.