Define authentication expectations for private federated nodes

The federation model assumes PROTOCOLS.yaml and protocol.md are fetchable over public HTTPS (raw.githubusercontent.com). A lab federating an internal or enterprise repository needs authenticated fetches, and the standard says nothing about how.

The need is real, but "define a credential-mapping standard" is a large surface that would duplicate git credential helpers, gh, and Docker config — and the runner is the wrong layer to reimplement any of them. The immediately valuable part of this issue is a prohibition, not a mechanism.

Prohibitions (specify these now)

1. Credentials must never appear in index_url or protocol_url. The runner emits both into the Method Provenance block before execution (SKILL.md, step 5.2), and that block is written into logs and pasted into manuscript Methods sections. A token embedded in a URL is therefore not merely exposed, it is transcribed into the permanent scientific record — and into PROTOCOLS.yaml, since protocol_url values are generated into the published index and committed by actions/generate-index. Any registry or index entry carrying userinfo or a query-string token is invalid.
2. Agents must not prompt the user to paste a token into the conversation, and must not store one. A PAT in a transcript is a leaked PAT.

Mechanism (specify minimally)

3. PROTOCOL_STANDARD.md states that an index_url or protocol_url may require authentication, and that a conforming agent obtains credentials from the host environment's existing mechanism — gh auth, a git credential helper, or the platform's standard credential store — rather than from the registry, the index, or the user.
4. protocol-runner gains a short section on authenticated fetches: which mechanism it uses, and the required behavior on 401/403 — report which node could not be fetched and continue with the rest of the federation, rather than failing discovery wholesale or silently dropping a node from the candidate list. A protocol that is invisible because of an auth failure must not be indistinguishable from one that does not exist.

Relationship to #23

waldronlab/agent-protocol-standard#23 (ad-hoc repositories) covers largely the same use case — private and pre-publication protocols — reached by a different route. Kept separate because that issue is about how an unregistered node is trusted and ranked, and this one is about how its bytes are fetched; a private node may well be both registered and authenticated.

Note that a private node registered in the central registry.yaml is publicly advertising its existence and URL while refusing access — that is a reasonable thing to want, but the schema work in waldronlab/agent-protocol-standard#22 should say whether it is permitted, since every consumer will fetch it and get a 403.

Start with PROTOCOL_STANDARD.md and SKILL.md step 5.2, then inspect protocol-runner's authenticated-fetch behavior and actions/generate-index. Done means credentials are prohibited in URLs and conversations, host credentials are used for authenticated fetches, and 401/403 errors identify the node while federation continues.