cli: improve macOS keychain write-failure messaging and first-run UX

[gbrlcustodio]

Problem

pipefy auth login from a fresh install on macOS surfaces this when the keychain write fails:

Login succeeded but the session could not be stored in your OS keychain (Keyring):
Can't store password on keychain: (-25244, 'Unknown Error').
On headless Linux, ensure a Secret Service daemon (gnome-keyring, kwallet) is running,
or use a static PIPEFY_TOKEN.

(packages/cli/src/pipefy_cli/commands/auth.py:205-213.)

Two issues:

1. The hint is platform-wrong. The user is on macOS; the hint talks about headless Linux Secret Service daemons. Confusing.
2. The actual cause isn't named. On macOS, -25244 (errSecParam) from SecItemAdd typically fires when Security.framework cannot surface the new-item ACL dialog to the user — e.g. when invoked from a non-TTY subprocess of an editor / IDE / agent host that doesn't share an interactive Aqua session. The failure is independent of how pipefy was installed. It hits both uvx --from <git+url> (ephemeral binary) and uv tool install-installed persistent binaries when the calling subprocess can't render the keychain prompt. The OAuth handshake itself succeeds; only the keychain persistence step rejects.

The fix users have to discover today: run pipefy auth login once from their own Terminal.app session, click Always Allow when macOS prompts to grant the Python binary access to the pipefy keychain item. From that point on, the keychain ACL remembers and the slash command (and refresh writes) work from subprocesses.

Surfaced during the workstream-C smoke test (#229): /pipefy:login via the Claude Code plugin completed OAuth but failed to persist, leaving users with a non-actionable error.

Proposal

Branch the error message on platform.system() in the KeyringError handler at packages/cli/src/pipefy_cli/commands/auth.py:205-213:

```python
except KeyringError as exc:
hint = _keychain_hint_for_platform()
typer.echo(
f"Login succeeded but the session could not be stored in your OS "
f"keychain ({keychain_backend_name()}): {exc}. {hint}",
err=True,
)
raise typer.Exit(1) from exc
```

_keychain_hint_for_platform() returns:

• macOS: "This is usually macOS denying the calling subprocess access to the keychain ACL prompt (errSecParam, -25244). Run pipefy auth login once from a regular Terminal.app session and click Always Allow when macOS prompts; subsequent runs (including agent / IDE integrations) will write without prompting."
• Linux: existing headless-Secret-Service hint.
• Windows: a Credential Manager equivalent (or generic).
• Unknown: generic fallback referencing pipefy auth status + docs.

Optionally also detect non-TTY callers up front (sys.stdin.isatty(), absence of TERM_PROGRAM, etc.) and warn before invoking store_session that first-time keychain access needs to be primed from a terminal.

Acceptance

• Running pipefy auth login on macOS in a context where the keychain dialog can't surface emits a message that explicitly says "run once from Terminal.app and click Always Allow" — no mention of headless Linux on macOS.
• Running on Linux still emits the Secret Service hint.
• errSecParam (-25244) is named in the error so users can grep for it.
• docs/cli/auth.md documents the macOS first-run keychain ACL step.

Why this is separate from #229 / #233 / #234

The plugin-installed CLI surface (#229), the PIPEFY_AUTH_URL default (#233), and the release-wheel migration (#234) don't touch this error path. It's a pipefy-cli UX concern that fires after OAuth succeeds — pure CLI message work. Lands cleanly on its own.

Refs #229.

[gbrlcustodio]

Repro attempt: per-binary ACL theory disproven

Tried to reproduce errSecParam (-25244) under controlled conditions on the same machine where it originally failed:

1. Deleted the existing pipefy keychain entry via security delete-generic-password -s pipefy -a 'signin-piporacle.pipefy.com|pipefy-cli'.
2. Called keyring.set_password('pipefy', 'signin-piporacle.pipefy.com|pipefy-cli', '<small payload>') directly from the uv-tool-installed Python (~/.local/share/uv/python/cpython-3.12.6-macos-aarch64-none/bin/python3.12) — the exact same interpreter that previously failed via pipefy auth login.
3. Repeated with a 5.6 KB JSON blob mirroring StoredSession's shape.
4. Repeated with a brand-new keychain service name never used before on this machine.

All three succeeded. No -25244, no macOS dialog, no prompt. The uv-managed standalone CPython interpreter does not require pre-approval to write to the user keychain — at least under the current macOS Security.framework state on this machine.

codesign -dvvv shows both interpreters are ad-hoc / linker-signed with no Apple Developer identity, only differing by CDHash:

• uv-managed: adhoc, linker-signed, identifier -
• Homebrew: adhoc, identifier python3-<hash>

Implication: the original -25244 was likely transient (Security.framework retry semantics, Aqua focus / lock state at the time, or a one-off param-validation hiccup), not a deterministic per-binary ACL gate.

Adjusted recommendation for the fix

The platform-aware error message proposed in the issue body is still worth shipping, but the macOS hint should be softened:

macOS Keychain denied this write (errSecParam (-25244)). This is often transient. Retry the command; if it still fails, run pipefy auth login once from a regular Terminal.app session as a fallback.

Drop the strong claim that the user must prime the binary via Terminal.app — empirical evidence does not support that.

Slash command bodies and docs/setup.md were softened correspondingly in branch feat/plugin/pipefy-login (commit 43b9cc7).