Deprecate payment-denom and direct-principal API surface ahead of single-denom vaults

[nullpointer0x00]

Summary

Follow-up to #239. That issue blocks new mixed-denom vaults; this one marks the existing payment-denom and direct-principal surface as deprecated so integrators stop building against it before it is removed in a later release.

Motivation

The plan is to flatten underlying/payment into a single underlying denom and rework direct principal mutation into a payments-style accept/reject API. The production nvYLDS vault uses none of the surface below (underlying == payment, no direct principal deposits/withdrawals). Deprecating now matters because nvHOME and Blacklake are building portfolio-vault integrations, and Blacklake is integrating directly on chain; anything they adopt from this list becomes a long-term legacy API obligation.

Candidate surface to deprecate

Mixed-denom concept:

• payment_denom on Vault and MsgCreateVaultRequest
• initial_payment_nav on MsgCreateVaultRequest
• redeem_denom selection on swap-out (the underlying-or-payment choice collapses to underlying only)
• The uylds.fcc NAV-check exemption noted in vault.proto

Direct principal mutation (to be reworked into the payments API):

• DepositPrincipalFunds
• WithdrawPrincipalFunds

Evaluate (tied to payment-denom pricing, but also used elsewhere):

• UpdateVaultNAV / UpdateNAVAuthority and the per-vault internal NAV entries for the payment denom

Scope

• Add deprecated = true proto annotations and deprecation notes on the fields/RPCs above.
• Update spec docs in spec/ to mark the surface deprecated and point at the replacement direction.
• Changelog entry announcing the deprecation window.
• Confirm the final list against what nvYLDS actually exercises; anything it uses stays.

Out of scope

• Actually removing the surface or implementing the replacement payment endpoints (separate design/release).