fix: allow first-time HODLMM deposit bins

[macbotmini-eng]

Summary

Fixes the first-time HODLMM deposit path for bitflow-hodlmm-deposit.

The skill documentation says first-time deposits into valid protocol bins are supported, but the live Bitflow user-bin endpoint currently returns HTTP 404 when the wallet has no existing pool bins. That observed response should mean "no existing wallet position yet," not "the pool is unusable," after the separate pool and bin metadata checks pass.

API surface check

Live spec checked: https://bff.bitflowapis.finance/api/app/openapi.json

• Spec identity: BFF API 1.0.0, OpenAPI 3.1.0.
• /api/app/v1/pools/{pool_id} is documented as Get Pool By Id: pool metadata by pool id.
• /api/app/v1/pools is documented as pool listing/filtering metadata.
• /api/app/v1/users/{user_address}/positions/{pool_id}/bins is documented as Get User Pool Bins: bin information for a specific user and pool, with fresh=true support and user-position cache/fallback headers.
• The user-bin operation documents 200 and 422 responses; it does not document 404 as a pool-existence signal.

That split is the behavior this PR codifies: pool validity comes from pool/bin metadata checks, while the user-bin endpoint is wallet-specific position state. A missing user-position row for a wallet with no existing bins is not enough to reject a first-time deposit when the pool metadata and protocol-bin data are valid.

Quote-side cross-check: https://bff.bitflowapis.finance/api/quotes/openapi.json documents /api/quotes/v1/bins/{pool_id} as pool bin reserves, prices, and liquidity information, which is the protocol-bin side of the same separation.

Change

• Treat the specific HTTP 404 ... has no pool bins user-position response as an empty wallet-bin set.
• Preserve all other 404s and API failures as errors.
• Leave selected protocol-bin validation, token balance checks, postconditions, and deny-mode transaction safety unchanged.

Validation

Pre-proof route validation, before the #559 route consumed the funded sBTC:

• bun run skills/bitflow-hodlmm-deposit/bitflow-hodlmm-deposit.ts status --wallet SP2G6TM8JCRNK6WSPQE8S86FP2W3A4FEVGZCCCQT8 --pool-id dlmm_1 --amount-x 4300 --amount-y 0
  • returned success
  • selected active bin 700
  • reported hasExistingPosition: false
  • postcondition mode remained deny
  • postconditions included wallet sends <= 4300 sBTC

Current live reruns with the same 4300 amount now correctly block on insufficient sBTC because that balance was used by the #559 proof route. The important behavior from this PR remains verified: the specific first-time has no pool bins API response no longer stops planning before pool/bin metadata, token balance, and postcondition checks run.

Additional checks:

• GitHub Actions posted validation passed for bitflow-hodlmm-deposit with 0 errors and 0 warnings.
• bun run scripts/validate-frontmatter.ts
  • bitflow-hodlmm-deposit passed with 0 errors and 0 warnings
  • full repo validation still reports pre-existing unrelated failures in dca, stacking-delegation, and zest-yield-manager
• git diff --check
  • passed

Why this matters

This is required for composed routes like #559 where the first route proof starts from idle sBTC and creates the wallet's first HODLMM position in an existing pool/bin.

[github-actions]

✅ Validation Passed

Skill: bitflow-hodlmm-deposit
Errors: 0
Warnings: 0

All checks passed. This submission is ready for review.