fix(check_config): report the source a connection actually came from

[PYDuquesnoy]

check_config could not tell an explicitly pinned connection from a blind port scan. Both reported connection_source: auto_discovered and both carried the fallback warning telling the operator to pin an instance that was already pinned.

Same binary, same instance, same probe script:

	before	after
IRIS_HOST=localhost IRIS_WEB_PORT=43080 …	auto_discovered + warning	explicit_flag, no warning
no IRIS_* at all	auto_discovered + warning	auto_discovered + warning

Cause

ConnectionSource was chosen by config_path.is_some() alone, so everything without a .iris-agentic-dev.toml became AutoDiscovered — and ConnectionSource::EnvVars was assigned in exactly one place, new_disconnected, meaning no live connection could ever report it.

The answer was never missing. discovery.rs stamps DiscoverySource on the connection; the mapping discarded it. ConnectionSource::for_connection now asks the connection, with a config file still winning as the narrowest statement of intent.

Why it mattered

The #21 fallback warning exists to flag the one genuinely dangerous state — a blind scan can silently land on the wrong instance. Firing it on every env-registered setup (every workshop VM, every ~/.claude.json with an env block) buried the case it was built for. 0.18.0 widened it: a VS Code-resolved connection is explicit configuration too and got the same treatment.

is_explicit() replaces a hand-written variant list at the call site, so the reported value and the predicate cannot drift apart again — the #169 shape, one function rather than two lists.

Tool description

It documented connection_source (http|docker|disconnected) — three values the code cannot emit. It now names the real set and states the rule that carries the meaning: only auto_discovered is a guess, and it alone gets the warning. Hint text is model-facing contract, so a wrong value set there is the same defect as a wrong label.

A label I predicted wrong

I expected env_vars for an env-pinned server and got explicit_flag. mcp.rs:86 builds the connection from self.host, which clap fills from --host or $IRIS_HOST — one value by the time it is stamped, so discovery's env-var step is effectively dead on the MCP path.

is_explicit is correct either way, so the defect is fixed. But rather than ship a name that implies "flag, not env", ExplicitFlag now documents that it covers both. Deliberately not plumbing clap's value_source() to separate them: more precise, not what this issue is about, and it touches the bin crate's arg handling.

I also renamed my own test env_vars_is_reachable_for_a_live_connection → env_var_discovery_maps_to_env_vars. The old name was true but would have been read as a stronger claim than it supports — it proves the mapping, not that the server emits it.

Scope

Version 0.19.0 — connection_source's value set is consumer-facing contract. 5 new unit tests; lib suite 595 → 600. Gate as one command: fmt, clippy -D warnings, full workspace → 47 suites green.

Issue 192 is addressed by this change.

🤖 Generated with Claude Code