[skip ci] Start branch for 0.3.3

See merge request computer-vision/cmd_queue!40

`with_textual` defaulted to 'auto', which resolves to textual whenever the
package merely imports. That let a transitive dependency decide which monitor
a user got, rather than how the queue was being driven.

Most queues run non-interactively: stdout teed to a log, over ssh, inside
docker, under an agent. A full-screen app there fills the log with escape
sequences and redrawn frames instead of job output, and can block on a
keypress nobody is present to press. The rich monitor degrades gracefully in
all of those, which makes it the better default.

Changed at every site that carried the 'auto' default:

  base_queue.Queue.monitor          backends/tmux.py (run + monitor + serial)
  backends/slurm.SlurmQueue.monitor cli_boilerplate CMDQueueConfig
  cmd_queue monitor CLI             cli_boilerplate CmdQueueConfigMixin

Deliberately unchanged: the `if with_textual == 'auto'` resolution branch, so
an explicit 'auto' still behaves as it always did, and the doctest that passes
it. Only defaults moved; `--with_textual=1` opts in.

Reported from a real session: `cmd_queue monitor --manifest=...` still came up
textual after the downstream default was changed, because the standalone CLI
carries its own default.

76 tests pass, 7 skipped.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Reported as "the rich interactive status stopped showing" after the textual
monitor was defaulted off. The status display was not removed -- it was being
written somewhere invisible.

`rich.live.Live` only animates when its console is a terminal. Our runners tee
stdout to a log, so the queue's stdout is a pipe, and Live silently degrades to
printing one frame when the context exits. Over a queue that runs for an hour
that means nothing on screen until the end. The textual monitor never showed
this because it drives the terminal directly, so `with_textual='auto'` had been
hiding the problem rather than avoiding it.

The Live display now opens /dev/tty and renders there when stdout is not a
terminal: the log keeps the ordinary output, the operator keeps a live view.
With no controlling terminal at all -- CI, pytest, nohup -- there is nothing to
attach to and it falls back to the previous console, so non-interactive runs
are unchanged.

Verified against a real pty: with stdout mocked non-tty, the monitor gets a
Console with is_terminal True whose output arrives on the terminal, and with
/dev/tty unavailable it returns the default console. 77 tests pass, 6 skipped.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

An overnight run could sit forever on "Do you want to kill the other
sessions? [y/n]" having done no work. Three things were wrong.

`auto` asked whenever `has_stdin()` was true, and that only checks stdin has a
file descriptor -- true under nohup, under cron with `</dev/null`, behind a
pipe, and inside a detached tmux. So it resolved to 'ask' for precisely the
runs that cannot answer. New `is_interactive()` requires stdin AND stdout to be
terminals. `has_stdin()` is left alone; the textual monitor asks a different
question with it.

The CLI default was `ask`, not `auto`, so the interactivity logic was never
even reached from a config-driven queue. Now `auto`.

And every same-named session counted as a conflict, including the leftovers of
a finished run -- which are the useful ones, since that is where you look to
see what failed without hunting logs. `session_is_busy()` now inspects panes: a
worker that finished is back at its shell prompt and its session is inert, so
it is reclaimed silently. Only a live foreground process prompts, and the
message prints `tmux attach` beside `tmux kill-session` because looking first
is usually the point. Unreadable panes count as busy -- the safe error is to
leave something alone rather than kill something that might be running.

`--non_interactive` lets a caller declare nobody is present: `auto` resolves to
`kill`, no prompt can appear, and the caller accepts that a running conflicting
session dies without being asked.

9 new tests; 86 pass, 6 skipped.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>