fix(skills): say which credential a skill pack sent, and keep it out of the error

[brahyam]

What

When a skill pack fails to clone, the error an operator reads is git's:

fatal: could not read Username for 'https://…': terminal prompts disabled

That sentence describes a missing credential, and the fetcher raises it verbatim. It is what git says whenever the server answers 401 and there is no terminal to prompt at — equally true when a credential was sent and refused. The reader cannot tell the two apart, and the message actively points at the wrong one.

The fetcher knows which case it is in, so it now says. Four situations, each with a different remedy:

situation	appended
a pack-named credential was sent and refused	the credential this pack names (repo-token) was sent as the Authorization header and the server refused it
a connector token was sent and refused	a connector token for this host was sent as the Authorization header and the server refused it
the pack names one that did not resolve	no credential was sent: the one this pack names (repo-token) is missing, disabled, or delivered by environment rather than through the broker
the deployment resolves none at all	no credential was sent: this deployment resolves none for skill packs, so a pack can only reach a public repository

The distinctions are not cosmetic. wiring.ts omits resolveAuth entirely when there is no keychain, and filters an env-delivered credential to undefined — so a blanket "this pack has no credential" blames the pack for two things that are not its fault and sends an operator to set a field they already set. Naming the connector-token path separately matters for the same reason: its remedy is reconnecting the account, not editing the keychain.

The 404

GitHub answers a valid but unauthorized token with remote: Repository not found. rather than 403, deliberately, so as not to leak repository existence. That is the most common real authorization failure on the one host this file special-cases, and it does not look like an auth error at all. A not-found now carries the ambiguity it actually has — that a repository which does not exist and one the credential cannot see are answered the same way — followed by which credential was sent.

The credential was still in the error object

The thrown message was masked while { cause: e } kept execFile's original error, whose .stderr holds the injected Authorization header verbatim. util.inspect walks causes by default, so console.error(err) printed the credential in full. Only a masked copy of the cause is attached now.

This is why the new scrub() coverage asserts against inspect(err, { depth: 4 }) rather than err.message — the first version of that test passed while the object being thrown still carried the secret, which is worse than having no test at all.

Smaller things in the same path

execFile's message ends in a newline, so the appended clause landed on its own line after a stray space; the message is trimmed first. A failure that is about neither credentials nor a missing repository passes through byte-for-byte, with no dangling separator.

Where this message still does not reach an operator

registerSkillPack catches the fetch failure, writes it to lastImport.error, and returns the pack — so POST /v1/admin/skill-packs answers 200 and the admin renders it as success. Nothing in the admin reads lastImport.error. So on the register path, which is where a mistyped authCredentialSlug is most likely to be introduced, an operator sees "registered" and a row with no skills, and never reads this sentence; only /sync and /catalog surface it.

That is a real gap and it is not this file's to close — it is either a UI change or a change to what the register route returns. Worth a follow-up.

Verified

test/pack-fetcher.test.ts covers all four situations, the 404, and the untouched pass-through.

It also gains the first test of scrub() in the repository. The stub git echoes its injected GIT_CONFIG_VALUE_* back on stderr, and the test asserts the header appears as Authorization: *** and that neither the secret nor its base64 form survives. Without the stub actually emitting the credential, every "the secret does not appear" assertion passes on a stub that never had it to leak — which is what the first version of this test did.

npm run typecheck, lint and prettier --check pass.

---

Related: #938 changes a different function in the same file (src/skills/pack-fetcher.ts) and adds cases to the same test file. Each stands alone; whichever lands second needs a rebase. #941 is the companion referred to above: it validates the slug this message names.