[skyflow-himanshupal]

Implements the nine unary FlowVault operations in the new flowvault Go module, on the generated FlowService /v2 client, with samples. Depends on SK-3222 (adds the common and flowvault modules); merge that first.

Why

• FlowVault needs a Go SDK at parity with the Java and Python FlowVault SDKs.
• SK-3222 added the module structure and the generated client; this PR adds the SDK on top of it.

Goal

• Insert, Update, Get, Delete, Detokenize, GetTokens, Query, UploadFiles and DeleteFiles work against FlowVault vaults, following the design doc and Java/Python behaviour:
  • table name and upsert at exactly one level (request or every record); request-level UpdateType
  • per-record results for partial failures, including non-2xx responses that carry records; whole-call failures return SkyflowError with the request ID
  • per-call headers through an Interceptor on every operation's options
  • timeout and retries (408/429/5xx, backoff with jitter), set per client (WithHttpConfig) or per vault; retries off by default
  • UploadFiles gets signed URLs, then uploads at most 5 files at once on a separate client: no retries, no overall timeout, no SDK headers
• Client is safe for concurrent use; a credentials change drops cached tokens.
• FlowVault vaults are reached on the skyvault subdomain (the SK-3222 skeleton had v2's vault domains).
• samples/flowvault: one sample per operation, plus custom headers, timeout/retry config and service-account token generation (same set as Python).

Changes outside flowvault (commit 6115e81, pinned in v2, flowvault and the samples):

• common/vault: shared generic interfaces (Inserter[Req, Opts, Resp], …) that both the v2 and flowvault vault services implement (compile-time checks only).
• common/config: HttpConfig and the HTTP fields on VaultConfig.
• common/config: Env now starts at 1, so 0 means "not set" (still resolves to PROD). UpdateVaultConfig in v2 and flowvault keeps the current Env when an update doesn't set one; before, it reset to PROD. Behaviour note for v2: code that stores or compares Env as a raw number sees values shifted by one.

Removed: the client-level WithCustomHeaders from the SK-3222 flowvault skeleton (it was never wired up, and isn't in the design doc). v2's WithCustomHeaders is unchanged.

Non-goals: bulk/async operations, separate connect/read/write timeouts, the Go e2e suite in sdk-integration-tests and the flowvault README (follow-ups).

Testing

• Unit tests for every operation against a fake FlowService server through the real generated client (request shape, response mapping, per-record and whole-call errors, retries, upload behaviour, concurrent use). All pass with -race; lint shows 0 issues on flowvault and v2.
• Fake API keys live in flowvault/test/resources, so gitleaks reports nothing.
• Ran against the FlowVault dev vault used by the Java/Python e2e suites: Insert (incl. per-record tables and partial failure), Get, Update, Delete, GetTokens, Detokenize, Query and validation all pass.
• Not yet verified on a real vault: UploadFiles and DeleteFiles. The dev file servicet, including a raw request without the SDK (e.g. request IDs
  0099c30e-548d-4ccc-b0a0-5a70cf13163c, 9d458b74-c392-425f-9485-9be1c1258cbb). To be re-run once it is back.
• v2: builds and passes lint; its tests show the same 34 failures as main locally, all needing CI secrets.

Tech debt

• v2, flowvault and the samples pin common to a pseudo-version of 6115e81. After SK-3222 merges and this branch is rebased, the pins must be updated to the merged common (or a common/vX.Y.Z tag).
• samples/flowvault/go.mod uses a local replace for flowvault until it is published.
• CI still only builds and tests v2; jobs for common, flowvault and the samples are needed.

[promptless]

Promptless documentation updates

• SK-3223 Add Flow Vault Go SDK README and update v2 Env docs adds flowvault/README.md for the Go SDK and updates the v2 docs for the Env change in UpdateVaultConfig. Docs PR