#9927 feat(credentials): saved credentials for Amplitude, Kalshi, Splunk, CB Insights, Railway, and Qdrant; fix Kalshi Ed25519 signing

Summary

• Moves six integrations that took secrets inline onto saved credentials. Each one adds a token credential provider, a check validator that makes one cheap, read-only, documented, non-billable request, a credential policy on every tool, and a credential-only successor block built with withSavedCredential.
  • Amplitude (amplitude_v2): API key, secret key and region, checked with GET /api/2/events/list on the region's host. User Profile now sends both saved keys over Basic auth, the only scheme in Amplitude's User Profile docs. Inline calls that pass only the secret key keep the Api-Key header they sent before.
  • Kalshi (kalshi_v3): key ID and private key, checked with a signed GET /portfolio/balance. Only the operations that sign requests use the credential.
  • Splunk (splunk_v2): token and management URL, checked with authentication/current-context through guarded egress. TLS verification is never relaxed.
  • CB Insights (cbinsights_v2): client ID and secret, checked with POST /v2/authorize.
  • Railway (railway_v2): checks depend on the token type. An account token reads me, a workspace token reads workspace(workspaceId), and a project token reads projectToken with the Project-Access-Token header.
  • Qdrant (qdrant_v2): API key and instance URL, checked with GET /collections through guarded egress.
• Fixes Kalshi request signing for Ed25519 keys, which is Kalshi's default key type. Before this, every authenticated call with an Ed25519 key failed.
• Small additive extensions to shared code:
  • Token credential fields gain optional multiline and optional flags. optional applies to a domain or workspace field in pasted-token mode. The create contract, the connect form and the secret builder all honor it, and the token is always required.
  • tokenCredentialOAuth gains an optional tokenReplacesParams list.
  • The saved-credential contract accepts any credential param filled by the token, not only accessToken.
• Not shipped:
  • RevenueCat: no documented v1 read proves the key without side effects. GET /subscribers/{id} creates a customer.
  • SAP S/4HANA: no read endpoint is guaranteed to be enabled for every Communication Arrangement.

Product decision: the legacy Splunk block is hidden

• The legacy Splunk block is hidden from the toolbar, like every other block with a saved-credential successor. Existing Splunk blocks keep their username/password inputs and run unchanged.
• A new Splunk block now needs token authentication. Splunk's docs say token authentication is off by default. Turning it on needs TLS, the KV Store and the edit_tokens_settings capability. Deployments that cannot turn it on can't add a new Splunk block until a username/password credential exists.
• Follow-up design: a saved Splunk login can't be expressed today. A tool's credentialParams are fixed, so one splunk service can't fill authToken for one credential and username/password for another. Two options:
  • Add a login authMethod that exchanges the username and password at execution time (POST /services/auth/login) for a session key, sent as Authorization: Splunk <sessionKey>.
  • Let a credential policy choose its params per authMethod.
    Either one changes shared resolve code and the Splunk tools' auth scheme, so neither is in this PR. If reviewers prefer, the legacy block can stay in the toolbar until then.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

• Each validator's failure modes were tested first and watched fail:
  • right host, auth scheme and egress
  • key refused
  • a 200 with an unexpected body not taken as proof
  • bad input refused before any request
• Optional credential fields: required-field derivation, the stored blob, and a revert proof.
• Amplitude User Profile goes through the executor with a saved credential (Basic auth over both keys; red before the fix). The inline secret-key-only call keeps the Api-Key header.
• Kalshi signatures are verified for Ed25519 and PKCS#8 RSA keys, and unsupported key types are refused.
• The successor-block serializer matrix covers all six integrations.
• These checks pass:
  • check-block-registry (saved-credential contract)
  • block-successors
  • tool-metadata
  • deployment-config
  • integration-catalog
  • tool-param-reachability
• Backward compatibility, for reviewers:
  • Legacy blocks keep their inline inputs; they are hidden from the toolbar and point to their successors.
  • Existing provider ids and stored secret shapes are unchanged.
  • The optional flag is set only by the new Railway descriptor.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)