## 1. Bind Page Prefill and Idempotent Bind

- [x] 1.1 Load the account main phone on bind-page mount via `assetApi.getInfo` and prefill the phone input when present
- [x] 1.2 Allow sending a `bind_phone` verification code to the prefilled main phone
- [x] 1.3 Keep ordinary bind success returning to the previous page
- [x] 1.4 Keep mandatory login-gate bind success returning to the login page for manual re-login
- [x] 1.5 Show backend `msg` on bind rejection and stay on the page

## 2. Change-Phone Transactional Migration Display

- [x] 2.1 Keep old/new phone and verification-code inputs with `change_phone_old` / `change_phone_new` scenes
- [x] 2.2 Show backend rollback copy for the 10-item limit and the same-asset conflict
- [x] 2.3 Stay on the change-phone page on failure
- [x] 2.4 Refresh the homepage bound state after success (existing `onShow` reload)

## 3. Three-State Need-Bind-Phone Routing

- [x] 3.1 Keep `need_bind_phone` as the only phone-verification guide signal in login success
- [x] 3.2 Evaluate the three-state semantic in the homepage bind gate
- [x] 3.3 Re-check the binding state on every homepage entry, not only after login
- [x] 3.4 Confirm the homepage gate signal source with backend - decision: keep `asset/info.bound_phone`; `need_bind_phone` stays wechat-login-only

## 4. Regression Verification

- [ ] 4.1 New user without a main phone still binds a fresh number
- [ ] 4.2 Existing user with a main phone and an unassociated asset can prefill, send code, and bind idempotently
- [ ] 4.3 Bind with a number different from the main phone shows the backend rejection message
- [ ] 4.4 Change-phone limit/conflict errors show the fixed backend copy
- [ ] 4.5 Global-switch-off keeps the bind guide hidden