fix: Accept --session on plugin commands

[scotwells]

Fixes #304

datumctl assistant card --session swells@datum.net@api.datum.net failed with patch: unknown flag: --session. Only a --session placed before the plugin name was consumed by datumctl; put anywhere else it was forwarded to the plugin as one of its own arguments. The error named the plugin rather than datumctl, and the workaround was to switch the active session — the thing the flag exists to avoid.

You can now put --session where you'd naturally put it:

datumctl assistant card --session swells@datum.net@api.staging.env.datum.net
datumctl dns zones list --session alice@example.com@api.datum.net

datumctl takes the flag out of the command line wherever it appears and turns it into the DATUM_SESSION and API host the plugin already understands. Arguments after a bare -- are still the plugin's to interpret. The same handling now applies to a plugin's shell completion and --help.

Also: --session with no value fails with datumctl's own "needs a session name" message instead of clearing the override and quietly running as the active session.

Precedence

--session beats DATUM_SESSION, unchanged from the root command and from what the flag's own help says. A bad --session value fails immediately; DATUM_SESSION is still resolved lazily, so a stale export only breaks commands that actually need a session.

Scope

Narrowed deliberately to --session. The other global flags a plugin doesn't parse are not in the same class: plugins define their own --project, --org and -o (the assistant plugin does), so consuming those at the datumctl layer would break them. --session is the one flag datumctl owns end to end and no plugin defines.

Base

Stacked on #303 (feat/302-session-override), which introduces the global --session flag. There is nothing to fix on main — the flag doesn't exist there yet. Retarget to main once #303 lands.

Verified

• go build ./..., go vet ./..., go test ./... clean.
• New tests in internal/plugindispatch/session_override_test.go cover the flag after the plugin name, --session=, the -- boundary, the missing-value error, and a fake managed plugin asserting the argv and DATUM_SESSION/DATUM_API_HOST it receives. They fail on the parent branch and pass here.
• Manually, against the real assistant plugin: the flag after the subcommand prints the agent card, and pointing it at staging vs production actually changes the endpoint the plugin talks to (patch.staging.env.datum.net vs patch.datum.net), so the session is taking effect and not just being dropped. Also checked flag-beats-env, unknown session, ambiguous email, missing value, --help, and -o json still reaching the plugin.

🤖 Generated with Claude Code