`loom --mode json` fails immediately with "Agent is already processing" whenever Galaxy credentials are present

## Summary

Any headless `loom --mode json` invocation fails before the agent even
starts, as soon as `GALAXY_URL`/`GALAXY_API_KEY` are set (via
`~/.loom/config.json`'s active Galaxy profile or plain env vars). The CLI
exits 1 with:

```
Agent is already processing. Specify streamingBehavior ('steer' or 'followUp') to queue the message.
```

Only a `session` event is ever written to stdout — `agent_start` never
fires. This reproduces with **fake, invalid Galaxy credentials**, so no real
Galaxy account is needed to hit it, and no network call to Galaxy is
required to trigger it (see repro below). It also reproduces independent of
`--safe`, `--print`, and whether `--tools` even mentions `galaxy` — see the
isolation matrix.

This blocks the exact scripted/headless usage pattern the project's own
README documents (`--mode json`, Galaxy connected, agent surveys the
workflow registry while drafting plans).

## Environment

- `loom --version`: `loom 0.6.0 (pi-coding-agent 0.84.1)`
- Node: v22.22.3 (meets the `>=22.19` `engines` requirement)
- OS: macOS 26.5.2 (Darwin 25.5.0)
- Install: `npm install -g @galaxyproject/loom`

## Minimal reproduction (no real Galaxy account needed)

```bash
mkdir -p /tmp/loom-bug-repro && cd /tmp/loom-bug-repro

GALAXY_URL="https://example-fake-galaxy.invalid" \
GALAXY_API_KEY="dummy-fake-key-0000000000000000" \
loom --mode json --safe --no-tools --no-skills --no-context-files \
"Reply with exactly one word: ALPHATAU. Do not say anything else."
```

**Expected:** same clean single-turn exchange you get with no Galaxy env set
(session → agent_start → turn_start → message events → turn_end →
agent_end → agent_settled, exit 0).

**Actual:**

```
{"type":"session","version":3,"id":"019ffcd8-e52d-7329-9d5c-970bc19617a6","timestamp":"2026-08-13T20:38:20.717Z","cwd":"/tmp/loom-bug-repro"}
Agent is already processing. Specify streamingBehavior ('steer' or 'followUp') to queue the message.
```

(session id and timestamp will differ per run; the important part is that
only `session` appears before the error, and `agent_start` never fires.)

Exit code 1. Note the prompt here is a trivial one-word reply request with
`--no-tools` — it has nothing to do with Galaxy, RNA-seq, or any specific
task content. The only variable that matters is the presence of the two env
vars.

**Control (works fine):** remove the two `GALAXY_URL`/`GALAXY_API_KEY`
lines and rerun the exact same command — it completes normally.

## Isolation matrix

Each row is a full, separate invocation; only the listed column changed.
All failing rows produced the identical error text before `agent_start`, on
the first attempt, every time (5/5).

| Galaxy env set | `--tools` includes `galaxy` | `--safe` | `--print` | Result |
|---|---|---|---|---|
| no | yes | yes | no | works |
| yes | yes | yes | no | **fails** |
| yes | yes | no | no | **fails** |
| yes | no | yes | no | **fails** |
| yes | yes | yes | yes | **fails** |

Takeaways:
- Not related to `--safe` / `--dangerously-bypass-permissions` — fails both ways.
- Not related to `--print` (the documented one-shot non-interactive flag).
- Not related to whether `--tools` grants Galaxy-specific tools at all.
- Purely triggered by `GALAXY_URL`/`GALAXY_API_KEY` resolving to non-empty
(whether from `~/.loom/config.json`'s active profile or plain env vars).

## Suspected root cause (hypothesis, not confirmed against source)

The project README states that "When Galaxy is configured the agent surveys
the workflow registry and tool catalog while drafting plans." Our guess is
that this survey is dispatched as a second, separate turn/message to the
same agent session, fired concurrently with (rather than sequenced before)
the primary user-supplied message when driven through `--mode json`'s
positional-argument input path — tripping Pi's single-flight "already
processing" guard, which normally protects against a human sending a second
message while the first is still streaming. The interactive TUI path
presumably never hits this because a human can't literally submit two
messages in the same tick.

## Impact

Blocks any headless/scripted `loom --mode json` usage against a
Galaxy-connected profile — i.e., automated evals or CI-style runs that need
the full plan → route-to-Galaxy → execute loop, not just plan drafting
without a live Galaxy connection.

## Suggested test for a fix

Re-run the minimal reproduction above (dummy credentials are sufficient,
no live Galaxy instance required) and confirm:
1. Exit code 0.
2. Full event sequence present (`agent_start` through `agent_settled`).
3. Same check with real credentials and `--tools read,write,edit,galaxy`
against a live instance, to confirm the actual Galaxy-survey behavior
completes and sequences correctly with the user's turn rather than
racing it.

Start at the `--mode json` positional-argument path and the Galaxy configuration or environment-variable handling. Run the minimal reproduction with dummy credentials and compare it with the same command without `GALAXY_URL` and `GALAXY_API_KEY`. Done means exit code 0 with the documented event sequence through `agent_settled`, including checks with Galaxy tools enabled.

Written by the indexing model from the issue text.