fix(module/fish): keychain.fish deployed copy drifted from repo template; decide sync path + setup_secrets.sh alignment

[ycpss91255]

Agent Brief

Category: bug / enhancement
Summary: While debugging a stray keychain: can't find <path>; skipping warning on LG14, an agent edited the deployed ~/.config/fish/conf.d/keychain.fish directly to fix the trigger and tweak the auto-unlock UX, without updating the tracked template at module/config/fish/conf.d/keychain.fish. This is now a confirmed drift case (same class of problem as #278, different mechanism) and needs a decision on how the tracked template should be brought back in sync — across this machine's repo checkout and any other machine (e.g. 192.168.10.10) that received the stale template via fish.module.sh's install().

Current behavior:

• module/fish.module.sh's install() does cp -r "${_src}" "${HOME}/.config/fish" once; upgrade() only reinstalls fisher plugins and never re-copies the config directory. So once a machine is bootstrapped, its deployed conf.d/keychain.fish never resyncs from the repo template again — any repo-side fix (or any local drift) has no automatic propagation path in either direction.
• The originally deployed keychain.fish (still in the repo template, unchanged) parses IdentityFile entries out of ~/.ssh/config via awk, and calls keychain --eval $keys | source (first terminal per login, gated by a $XDG_RUNTIME_DIR/keychain.shown marker) or keychain --quiet --eval $keys | source (subsequent terminals).
• Root cause of the literal warning (separate, already fixed locally, not a template bug): ~/.ssh/config on LG14 had CRLF line endings, so the awk-extracted path carried a trailing \r, and keychain's [ -f "$pm_k" ] check failed. Converting the file to LF fixed it — this was a personal dotfile issue, not something the template caused.
• Confirmed via /usr/bin/keychain source (ssh_listmissing, ~line 1030): keychain already fingerprints the running agent's loaded keys via ssh-add -l before deciding whether to prompt, so it only invokes ssh-add (and only then shows a passphrase prompt) for keys not already loaded. The marker-file split in the template is therefore purely a verbose/quiet banner-text toggle — it has no effect on when the passphrase prompt itself appears.

What changed locally (uncommitted nowhere, deployed-file only):
~/.config/fish/conf.d/keychain.fish on LG14 was rewritten to drop the marker/verbose-vs-quiet split (functionally a no-op simplification per the above) and keep keychain --quiet --eval $keys | source unconditionally, so first-terminal-per-login still auto-prompts for the passphrase and later terminals silently share the already-unlocked agent. This matches the desired UX ("open a terminal → if the key isn't unlocked yet, prompt right there; once unlocked, every other terminal shares it"). This edit was not ported back to module/config/fish/conf.d/keychain.fish, so it is currently local-only drift on one machine.

Decision needed:

• Should module/config/fish/conf.d/keychain.fish be updated to the simplified form (drop the marker/quiet split), or is the marker's verbose-once UX intentional and worth keeping as-is?
• Does module/fish.module.sh need a resync mechanism (upgrade() re-dropping conf.d/ specifically, or something like the bidirectional sync_config.sh idea from feat(tool): sync_config.sh — bidirectional config sync between repo and ~/.config #308) so template fixes actually reach already-bootstrapped machines, and so ad hoc local edits either get captured back or are at least flagged as drift instead of silently persisting forever?
• Should the actual key-adding step route through setup_secrets.sh ssh-key load (issue feat(secrets): setup_secrets.sh - backend abstraction + ssh-key subcommands (Sec 14, AC-20) #44, AC-20 — passphrase entry owned by ssh-add on its own tty, this repo's actual tested/audited tool for this exact action) instead of relying on keychain's internal ssh-add call, for consistency with the rest of the secrets tooling? Or is delegating to keychain (which already does the equivalent fingerprint-check-then-add-if-missing dance) an acceptable, simpler alternative?
• Does 192.168.10.10 (and any other bootstrapped machine) need an explicit one-off resync of this file once a decision is made, given there's currently no automated path to get it there?

Key interfaces:

• module/config/fish/conf.d/keychain.fish — the tracked template
• module/fish.module.sh — _install_fish_config (cp -r, install-only, no upgrade resync)
• setup_secrets.sh / lib/secrets.sh — existing ssh-key load subcommand (issue feat(secrets): setup_secrets.sh - backend abstraction + ssh-key subcommands (Sec 14, AC-20) #44)
• ~/.ssh/config — per-machine, not a repo file; CRLF/permissions hygiene here is out of scope for this issue (personal dotfile, not template-caused)

Out of scope:

• The plaintext-secrets-in-~/.ssh/config / repo-tracked-personal-data problem — already tracked in refactor(ssh-config): stop version-controlling personal ssh_config; separate secrets from repo template #278, unrelated file
• Any specific machine's ~/.ssh/config permissions or CRLF cleanup — personal dotfile hygiene, not a repo template concern

[ycpss91255]

Follow-up: verified actual keychain output on both machines (LG14 + 192.168.10.10)

Captured the literal output of the exact command each machine's deployed conf.d/keychain.fish runs, to check whether the two machines are actually aligned and not just assumed to be.

LG14 (deployed-only fix, not yet ported to the repo template — see decision items below):

set -e SSH_AUTH_SOCK; set -x -U SSH_AUTH_SOCK ...
set -e SSH_AGENT_PID; set -x -U SSH_AGENT_PID ...

Always runs keychain --quiet --eval $keys unconditionally (no marker/verbose branch).

192.168.10.10 (unchanged repo template, still has the marker/verbose-vs-quiet split):

• First terminal per login (keychain --eval, verbose):

 * keychain 2.8.5 ~ http://www.funtoo.org
 * Starting ssh-agent...
set -e SSH_AUTH_SOCK; ...
set -e SSH_AGENT_PID; ...

 * Adding 2 ssh key(s): /home/yunchien/.ssh/coretronic /home/yunchien/.ssh/id_ed25519

• Subsequent terminals (keychain --quiet --eval): identical shape to LG14's output above.

Conclusion:

• Behavior is aligned: on both machines, the first terminal per login attempts the unlock (prompts for the passphrase if the key isn't already in the agent), and every later terminal silently shares the same already-unlocked agent. Confirmed via /usr/bin/keychain source (ssh_listmissing) — it fingerprint-checks the running agent via ssh-add -l before deciding to add, independent of --quiet.
• Literal output text is NOT aligned: 192.168.10.10's first-terminal path still prints the keychain version banner + Adding N ssh key(s): ... line that LG14's simplified version dropped. This is the same "decision needed" item already listed in the issue body (whether to port the simplified form back to module/config/fish/conf.d/keychain.fish, or keep the verbose-once banner intentionally).
• LG14's deployed dotfile was tested and works as intended (fresh terminal → ssh-add -l shows no identities → manual unlock prompts once → subsequent terminals share it). This is a single-machine, deployed-file-only state — not yet reflected in the repo template per the earlier decision to file this issue first rather than edit module/config/fish/conf.d/keychain.fish directly.

No code changes accompanied this comment; both machines' test/agent state (stray ssh-agent processes, ~/.keychain/* cache files) created during verification were cleaned up afterward on both sides.