[NF-23] [BACKEND] SDK: Expanded On-Chain Error Taxonomy

Overview

The SDK's error handling was scoped narrowly to VaultRouter's two error codes. With NF-20/NF-21 adding Governance and Harvester clients, this issue expands the SDK's typed-error surface to match every distinct on-chain failure mode those new clients can hit.

Problem

sdks/typescript/src/errors.ts exports exactly two error classes: LockNotExpiredError and BelowMinDepositError, both mapped only from VaultRouter's VaultError codes (InvalidTier, BelowMinDeposit, LockNotExpired). Once NF-20/NF-21/NF-22 land, callers will be able to trigger Governance/StrategyVault/Harvester failures (allocation-cap-exceeded, pool-not-allowlisted, proposal-not-pending, timelock-not-elapsed, already-vetoed, cooldown-not-elapsed) that the current SDK has no typed representation for at all — those would surface as raw, unstructured RPC/simulation error strings.

Proposed Solution

• Add error classes: AllocationCapExceededError, PoolNotAllowlistedError, ProposalNotPendingError, TimelockNotElapsedError, AlreadyVetoedError, HarvestCooldownError, all extending the existing YieldLadderError base class.
• Build a central error-code-to-class mapping function (e.g. mapContractError(code: number, contract: 'router' | 'governance' | 'strategy' | 'harvester'): YieldLadderError) used consistently by every client (VaultRouter, and the new Governance/Harvester/StrategyVault clients from NF-20–22) instead of each client independently guessing at error text.
• Replace the existing fragile isLockError string-matching helper (message.toLowerCase().includes('lock')) with proper contract error code inspection.

Acceptance Criteria

• Every new error class is exported and extends YieldLadderError
• A single shared mapping function is used by all SDK clients, not per-client ad hoc string matching
• The existing isLockError string-matching is replaced with code-based detection
• Existing LockNotExpiredError/BelowMinDepositError behavior is unchanged for current callers
• Unit tests cover: each new error class is correctly thrown for its corresponding on-chain error code, across at least one call from each of the four clients

Start with sdks/typescript/src/errors.ts, then trace error handling in VaultRouter and the Governance, StrategyVault, and Harvester clients from NF-20–22, including the existing isLockError helper. Done means all listed classes are exported, one shared code-based mapper is used by all four clients, existing behavior is preserved, and unit tests cover each mapped on-chain error.