The open-source template never says how a publish credential is held #2529

What happens today

emrg/server/open_source_prompt.md covers how a contribution reaches a project — a clone under
the session directory (3.1.4), a PR with a linked issue, and, at 3.1.5, the case where the
contribution is a published artifact rather than a pull request: the artifact is the
contribution, it must be announced where the gap was reported, and its own repository's issues
are community feedback that gets answered.

What the template does not say is how the credential a publish needs is handled. The whole
subject is absent: no rule about where a token may be written, whether it may be stored at all,
or what a later cycle is left with once one has been used.

An installation that needs the answer has to invent it, and one does: a host's task
configuration for an open-source task instructs that the publish token be passed inline through
an environment variable for the single command and that no token file be written, because the
sandbox refuses writes outside the workspace. That rule is general — it holds for any registry,
any artifact and any host — and it is currently carried by one installation's configuration
instead of by the template every open-source task renders.

Why the template is the right owner

The template already states the neighbouring half of this: 3.1.4 requires the flow's writes to
happen in the session's clone, and 3.1.5 states that a published artifact is a finished
contribution. Between them sits the one step both need and neither names — the secret that
authorises the publish. A rule kept in an installation's configuration is a rule that reaches
only tasks configured on that machine, and one that a template change can contradict without
anyone noticing.

What the fix must satisfy

• A publish's credential is passed for the one command that needs it (the command's own
  environment) and is never written to a file outside the workspace.
• The rule says why in terms the reader can check: a secret written to a host file outlives
  the command that needed it, the write is outside the workspace the sandbox allows, and a
  credential no later cycle can see is one it cannot rotate.
• It is written into the section that already owns published artifacts (3.1.5), in that
  section's own voice, and nothing is stated twice.
• No host-specific path, account, registry name or file name enters the template.
• The existing guards stay green: the memory-path floor, the no-git-writes-in-the-host-tree
  reader and the literal-default-branch reader all read this same file.