#3529 Remote resolveSecret allowlist is always empty for workflow steps that use vault.get

What happens

DispatchService derives a dispatch's allowedSecrets with extractVaultReferences over globalArgs and methodArgs (src/serve/dispatch_service.ts). Those args reach serve after MethodExecutionService has resolved vault expressions to plaintext, so a workflow step whose arguments use vault.get registers staticRefs empty and hasDynamicRefs false. CapabilityService then refuses every capability.resolveSecret for that dispatch, including the very secret the step referenced, with: secret is not referenced by the dispatched step. This also blocks remote readResource of tagged sensitive fields. It fails closed, so it is not a disclosure.

Existing remote integration tests do not catch it because they build CapabilityService without the dispatch registry, which turns the allowlist off.

Evidence

Found by the swamp-club#3512 baseline: integration/remote_secrets_baseline_allowlist_test.ts (end-to-end case) and integration/remote_secrets_baseline_read_resource_test.ts (tagged sensitive field case).

Expected

Derive the allowlist from the pre-resolution arguments (or the secret bag), so a step can read the secrets it references. Typed-secrets Phase 5 replaces this path; decide whether a legacy repair ships first.