fix(flags): stop reporting success for a flag that cannot take effect on this host

[filip131311]

Fixes #642.

Reproduced on a real Linux VM (Ubuntu aarch64, Node 20, published 0.18.0), not simulated:

$ argent tools | wc -l                          75
$ argent enable argent-lens
Enabled flag "argent-lens" (global). Stored at /home/filip.guest/.argent/flags.json.
$ argent tools | wc -l                          75      ← unchanged
$ argent tools | grep -c 'propose_variant'       0

After, on the same VM:

$ argent enable argent-lens                     # exit 0
stdout: Enabled flag "argent-lens" (global). Stored at /home/filip.guest/.argent/flags.json.
stderr: Note: "argent-lens" is macOS-only, so enabling it has no effect on Linux.

$ argent flags
  argent-lens   enabled  (global)  [macOS only — unavailable on Linux]

The gap

The darwin registration gate is deliberate and well-commented. What was missing is that
FLAG_REGISTRY carried no platform information, so the CLI could not know. A flag can now declare
platforms, and argent flags / enable render from it.

Note argent lens already told the truth on Linux ("macOS-only — it drives Terminal/iTerm via
osascript"). That asymmetry is the whole bug.

Decisions a reviewer should weigh

Warn and store, exit 0 — not refuse. enable authors portable state rather than performing an
action: flags.json gets committed, and a Linux teammate must be able to author project-scope config
for macOS colleagues. Refusing would also turn a silent no-op into a hard failure for any shared
bootstrap script running under set -e — a behaviour regression well beyond a message fix. The
counter-argument (exit 2 is unambiguous and machine-readable) is real; I weighted the regression
higher for a truthfulness fix.

The note claims nothing about other machines. An earlier draft ended "…and will apply on macOS."
That is false in the default global scope — ~/.argent/flags.json on this Linux box will never be
read by a mac — and wrong again under argent link, where registration and flag reads happen on the
remote host. The note now states only what is true of the host in front of you.

Reads stay platform-blind, permanently. isFlagEnabled sits in the per-request exposure path and
its package is documented as having no console I/O; more importantly, a flag committed by a macOS
teammate must behave identically here. There is a named test pinning this so a later "improvement"
gets caught with its reason attached.

The registration gate is NOT derived from the registry, though that was tempting for
single-source-of-truth. Deriving fails in the wrong direction: getFlagDefinition returns undefined
once the flag graduates and its entry is removed — and this flag's own description says "while the
feature is in development", so removal is the expected end state — which would register the Lens
tools on every platform, exactly what the gate exists to prevent. The two statements are pinned
together by a test that asserts registration matches the declared platforms across darwin/linux/win32.

flags --json reports platforms, not supportedOnThisPlatform. A per-host boolean encodes
process state as flag data and is wrong the moment the output is read elsewhere or under link.
Additive field; the one in-repo consumer is a test, updated here.

Also fixed: an infinite loop in the Lens skill

skills/argent-lens/SKILL.md told the model: if the tools come back not-found, the flag is off —
enable it and retry. On Linux enabling never creates them, and there was no terminal condition. It
now states the platform in the frontmatter description (the line a router reads before invoking
the skill, so a Linux agent isn't handed it in the first place) and gives the exit condition: do not
retry, tell the user.

Verification

Linux VM: exit 0 with the Enabled line on stdout and the note on stderr; flags.json written;
flags badge; --json platforms: ["darwin"] vs null for an unconstrained flag; tools | wc -l
still 75, proving registration was untouched; disable silent; an unconstrained flag gets no note.

macOS: enable silent on stderr, exit 0, both Lens tools still registered, badge renders
[macOS only] with no "unavailable" suffix.

configuration-core 93 passed, argent-cli 285 passed, tool-server 3087 passed.
Unchanged and still passing: registry-feature-flag-gate.test.ts, variant-flag-gate.test.ts and the
HTTP exposure tests — exposure semantics do not change.

🤖 Generated with Claude Code