feat(sdk-core): depositToVault with getVaultConfig and Concrete BTC support

[venkateshv1266]

Summary

• Add VaultProvider enum (Morpho, ConcreteBtccx) and named result types ConcreteDepositResult / MorphoDepositResult; update DepositResult union to use them
• Add getVaultConfig to DefiVault and IDefiVault, proxying GET /api/defi-service/v1/vaults/:id
• Add protocol dispatch in depositToVault: routes ConcreteBtccx → depositToConcreteVault, Morpho → depositToMorphoVault, else throws unsupported provider error
• depositToConcreteVault: single sendMany with type: 'defi-deposit' and defiParams; no recipients (WP resolves escrow destination server-side)
• Add defiParams: t.unknown to BuildParams whitelist and optional defiParams to SendManyOptions; bump @bitgo/public-types to ^6.39.0
• Unit tests: getVaultConfig happy path + error cases, Concrete dispatch (single sendMany, pendingApproval extraction, passphrase forwarding), Morpho regression guard

Test plan

• yarn unit-test -- --grep "DefiVault" in modules/sdk-core: all passing
• yarn build in modules/sdk-core: no TypeScript errors
• Morpho existing tests are green (regression guard)
• Concrete path: depositToVault with a concrete_btccx vault returns { pendingApprovalId, state }
• Unsupported provider throws descriptive error

CLOSES TICKET: DEFI-279

[linear-code]

DEFI-279

[nvjsr]

CI is failing

[OttoAllmendinger]

why are we still not using typed routes?

[vmccarty]

Breaking change linter override approve. Re:

Breaking change linter override approved. Re:

None of the 98 findings is the removal of a required, client-facing, in-production response field. So the premise ("each was intentionally broken elsewhere and got a DevEx override") doesn't map 1:1 — most aren't breaks at all. But every real change traces to a deliberate, reviewed, released public-types PR with a Linear ticket, and several were explicitly coordinated with the owning service:

Irys revert → #396 (SC-5765/6/7), owner-driven
DeFi clientIdempotencyKey/restructure → #389 (CGD-1400), #414 (CGD-2007, body: "Unblocks CGD-1821 (wallet-platform) and CGD-1822 (BitGoJS)")
Canton choiceArgument optional → v6.26.0
goStaking optionality → v6.29.0
The reason there's no override "in the public-types repo" is exactly the gap you identified: public-types has no breaking-change CI, and the consuming service (wallet-platform, which owns signtxtss/sweep) drove these via tickets rather than through a spec-diff gate.

Recommendation
Both PRs (9232 → 6.41.0; 9211 → ^6.39.0, same range, subset of the same findings) are safe to override and approve on client-impact grounds — the breaking-change gate is misfiring on oneOf reindexing, not detecting real contract breaks. I'd note in the DevEx override request: "All findings are positional oneOf artifacts in the signtxtss/sweep intent union from additive public-types changes 6.22→6.41 plus the intentional Irys revert (#396); verified surviving fields still present; no required client-facing field removed."

Two things I can do next if useful:

Pull the literal override/approval paper trail from wallet-platform (owner of these endpoints) to attach as corroboration — I'd need to add that repo to the session.
For the CI/pipeline fix: the concrete bug is the positional-index diff on large unions. The durable fix is a name/discriminator-aware oneOf comparison (match variants by intentType literal, not array position) in BitGo/static-analysis's breaking-changes rule — I can scope that out.
Want me to grab the wallet-platform override records, or start on the static-analysis fix?

[venkateshv1266]

Removed the bump commit (chore(sdk-core): bump @bitgo/public-types to 6.40.1) since a newer version was already merged to master, which was causing merge conflicts. Rebased the branch onto latest master — now only the feat commit remains.

[Marzooqa]

Codeowners should be updated