hub: four dispatch paths swallow secret-resolution failure behind debug flag

[ptone]

Observation

Four dispatch paths in pkg/hub/httpdispatcher.go call resolveAgentSecrets (or formerly
resolveSecrets) and continue silently when resolution returns an error. The failure is
logged at Warn level, gated behind d.debug (off by default). No consequence is stated.

The four sites

Path	Line (approx)	Variable	Shape
buildCreateRequest	654	err	if d.debug { d.log.Warn(...) } then continue
DispatchAgentStart	1878	err	if d.debug { d.log.Warn(...) } then continue
DispatchAgentRestart	2149	secretErr	if d.debug { d.log.Warn(...) } then continue
DispatchAgentResetAuth	2313	resolveErr	Fixed in PR #1333 — Error level, unconditional, consequence stated

After PR #1333, ResetAuth is the only site that logs at Error level with a stated consequence.
The other three remain debug-gated Warn.

What happens on failure

When resolution fails, the agent starts/restarts/is created without injected secrets and
without entitled keys recorded on the credential (NULL — fail-closed on future fetch via
the secrets endpoint).

Open question — unverified, worth checking

It is not established that an agent can generally function without secrets. If the harness
configuration requires an API key and secret resolution silently failed, the agent starts
and then exits — the operator sees an agent that died with no reason connected to the
resolution failure. The resolution error was logged only at debug level (off by default),
leaving no operator-visible trail between the cause (resolution failure at dispatch time)
and the symptom (agent exit, minutes later).

This is unverified. It is named here as a candidate cause for agents that exit without
a diagnostic, not as a confirmed link. Investigation would need to correlate agent-exit
events with secret-resolution failures on the same dispatch.

Notes

• The benign-error question matters before changing log levels on the three hot paths:
  if secretBackend.Resolve returns a non-nil error for "no secrets configured" (a normal
  condition), raising to Error on these paths would emit false alarms on every project
  without secrets. This must be checked first.
• PR refactor(hub): extract resolveAgentSecrets, return JTI hash from token gen (#127) #1333 does NOT change the three remaining sites — they are out of scope for the
  security refactor and the benign-error question applies to all three.

[ptone]

Additional observation: partial resolution silently narrows recorded entitlement

The entitled key list recorded on the credential is derived from secrets that successfully
resolved — specifically, from the return value of secretBackend.Resolve(). Inside both
LocalBackend.Resolve and GCPBackend.Resolve, individual secrets that fail GetSecretValue
or decryptRawValue are dropped via continue before being added to the merged map. The
backend returns nil error (partial success is indistinguishable from complete success at the
call site).

Since resolveAgentSecrets builds entitledKeys by iterating the resolved result
(httpdispatcher.go lines 2740–2741), a secret that exists but cannot be read or decrypted at
dispatch time is absent from the entitled set written to the credential. This is a durable
reduction — nothing recomputes the record until the agent is restarted.