Session management: session commands should join the default session by default, create-or-attach named sessions, and require --new to spawn fresh

[arcavenai]

Problem or motivation

The current forestage session commands (`forestage session start`, and friends in `src/session_cmd.rs`) create a new tmux session on every invocation. Running `forestage session start` twice in a row produces two separate tmux sessions, each with their own pane, and the user has to manually pick which one to attach to. There is no affinity between successive `session start` calls and no way to say "attach me to the session I already have" without naming it explicitly each time.

This is the wrong default for an interactive tool. The common case is "I want to keep working in the session I was just in", not "I want a fresh one every time". The current behavior is the kubectl-style "one command, one resource" mental model, but what the user wants is the tmux-style "session is the persistent thing, commands act on the current one by default" mental model.

Concretely, today:

• `forestage session start` — always creates a new tmux session, never joins an existing one
• `forestage session start foo` — if a session named `foo` does not exist, it's unclear from the CLI whether it errors or creates it; if `foo` exists, behavior is also unclear
• There is no default session affinity — the tool has no concept of "the session I'm currently working with"

Proposed solution

Redefine the session commands around a default session and create-or-attach named sessions:

Default session

forestage maintains a concept of "the default session" — by convention, a well-known session name (e.g. `forestage`, or a user-configurable value from `config.toml`):

[session]
default_name = "forestage"

`forestage session start` (no args)

• If the default session exists → attach to it (equivalent to `tmux attach -t forestage`)
• If the default session does not exist → create it, then attach
• `--new` flag → always create a new session; if the default name is taken, auto-name (e.g. `forestage-2`, `forestage-3`, …) or fail with a helpful error and suggest `--name`

`forestage session start `

• If `` exists → attach to it
• If `` does not exist → create it, then attach
• `--new` flag → error if `` already exists (prevents accidental overwrite / duplicate create)
• This is the "create-or-attach" primitive; one command, one name, deterministic outcome

`forestage session stop []`

• No arg → stops the default session
• `` → stops the named session
• Should be the inverse of start — whatever start created or attached to, stop should find and terminate

`forestage session list`

• Lists all sessions forestage knows about (its own + any created with its naming convention)
• Marks the default session explicitly
• Already mostly exists; verify it matches the new model

`forestage session attach []`

• Explicit attach, no create. Errors if the target does not exist.
• Useful for scripting and for users who want strict "attach but never create" semantics.

Alternatives considered

• Keep the current "always create new" behavior, add a `--attach` flag. Inverts the ergonomic: the common case (attach) requires a flag, the rare case (new) is the default. Wrong way around.
• Make `session start` always error if any forestage session exists, require explicit disambiguation. Too strict; adds friction to the common case without adding clarity.
• Model after git's stash or worktree commands (`forestage session create`, `forestage session checkout`, etc.). Heavier mental model; doesn't match tmux's existing vocabulary which the user already knows. Match tmux's conventions where possible; diverge only where forestage adds real value.
• Do nothing; let users run tmux commands directly. forestage already owns session management as a product surface — punting on ergonomics here means the feature is worse than bare tmux, which is a bad place to be.

Acceptance criteria

• `forestage session start` run twice in a row attaches to the same session both times
• `forestage session start --new` always creates a new session
• `forestage session start foo` creates `foo` if missing, attaches if present
• `forestage session start foo --new` errors if `foo` already exists
• `forestage session stop` without args stops the default session
• `forestage session stop foo` stops `foo`
• Config option `session.default_name` controls the default session name
• Documentation in `docs/session-management.md` updated with the new semantics and a rationale section on why attach-by-default is correct

Related

• This intersects with the broader B10 / F20 work on tmux-cmc session maturity and with forestage#15 (1:1 control session ratio) — the smart default from finding-006 (Pattern 1 direct attach for single session, Pattern 2 shared `_ctrl` for multiple) applies here too.
• Pane management (forestage#17) is a follow-up — once sessions join by default, the next question is "how do I get multiple panes in one session", which is a different issue.

References

• `src/session_cmd.rs` — current session command implementation
• `src/session.rs` — session lifecycle
• `docs/session-management.md` — current docs
• finding-006 — control session architecture (Pattern 1 / Pattern 2)

[arcavenai]

Confirmed fixed in forestage f6cb783.

$ forestage session list
No sessions on socket 'forestage'.
$ forestage session start                  # creates session 'forestage'
Creating session 'forestage'...
Session ready. Attach with: forestage-a session attach -t forestage
$ forestage session start                  # joins existing
Adding window to session 'forestage'...
Window added to session 'forestage'.
$ forestage session start --new            # creates fresh petname
Creating session 'forestage-mild-rabbit'...
$ forestage session list
forestage: 2 windows
forestage-mild-rabbit: 1 windows

Behavior matches the requested spec exactly.

Side note caught while testing: forestage session stop (no -t) with multiple sessions correctly refuses with Error: specify a session with -t, or use --all to stop everything. Nice defensive UX.