These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet/src/wallet/platform_addresses/transfer.rs`:
- [SUGGESTION] lines 119-127: No crate-local regression test pins the foreign-address skip
  The entire correctness fix for QA-010 is enforced solely by control flow in `transfer()` and `withdrawal()`, yet `rs-platform-wallet` adds no unit or integration test exercising a response that mixes owned input addresses with a foreign output address. The PR description defers validation to the parent #3549 e2e suite, but this protection should live with the code it guards: a future refactor of the post-broadcast ledger-update loop (moving the guard, factoring the body out, replacing `contains_platform_address`) could silently reintroduce the exact ledger-corruption bug while compiling cleanly and passing unrelated coverage. Add a focused test that feeds an `address_infos` map containing one owned and one foreign `PlatformAddress::P2pkh`, then asserts (a) `account.address_credit_balance` only reflects the owned entry, (b) the returned `PlatformAddressChangeSet` excludes the foreign entry, and (c) `total_credits()` does not absorb the foreign balance. The same fixture covers the symmetric guard in `withdrawal.rs`, which has no e2e coverage today.

let address_index = account
    .addresses
    .addresses
    .iter()
    .find_map(|(&idx, info)| {
        PlatformP2PKHAddress::from_address(&info.address)
            .ok()
            .filter(|found| *found == p2pkh)
            .map(|_| idx)
    })
    .ok_or_else(|| {
        PlatformWalletError::AddressSync(format!(
            "Owned platform address {} missing derivation index in account {}",
            p2pkh, account_index
        ))
    })?;

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

- [SUGGESTION] In `packages/rs-platform-wallet/src/wallet/platform_addresses/transfer.rs`:119-127: Ownership-guard regression is not pinned by a crate-local test
  The V27-007 / QA-010 correctness fix is enforced solely by the new `if !account.contains_platform_address(&p2pkh) { continue; }` branch in `transfer.rs:125` and the mirrored guard in `withdrawal.rs:135`. `packages/rs-platform-wallet` ships no unit or integration test that exercises an `address_infos` payload mixing an owned input with a foreign output and asserts (a) the foreign address is not written into `account.address_balances`, (b) the returned `PlatformAddressChangeSet` contains no entry for the foreign address, and (c) the persister is not called with foreign rows. The PR defers validation to the parent #3549 e2e suite, but because this PR is carved out as a standalone backport on `v3.1-dev`, the invariant has no in-repo guard — a future refactor of the post-broadcast loop (see the duplication finding) could silently delete or invert the branch with no CI signal here. A small focused test constructing a `ManagedPlatformAccount` with one owned address and one foreign `PlatformP2PKHAddress` in `address_infos` would pin the invariant where it lives.
- [SUGGESTION] In `packages/rs-platform-wallet/src/wallet/platform_addresses/transfer.rs`:139-149: `unwrap_or(0)` can silently mis-key a persisted row for an owned address
  After the new guard, this lookup only runs when `account.contains_platform_address(&p2pkh)` is true. That predicate (in `key-wallet/.../managed_platform_account.rs`) returns true if the address appears in EITHER `address_balances` OR `addresses`. The subsequent `find_map` only iterates `account.addresses.addresses` (the indexed pool), so an address present in `address_balances` but missing from the pool's indexed map passes the guard and falls back to `address_index = 0`. That fabricated index is then propagated through `PlatformAddressBalanceEntry` and `self.persister.store(...)`, overwriting the persisted row at derivation index 0 with another address's balance/nonce. The identical pattern is present in `withdrawal.rs:149-159` and `fund_from_asset_lock.rs:130-140`. Before the guard this was masked by broader corruption; under the new invariant it is a concrete failure mode. The correct response is to surface an error (this is now an invariant violation, not a normal case) rather than coerce to 0.
- [NITPICK] In `packages/rs-platform-wallet/src/wallet/platform_addresses/transfer.rs`:114-157: Post-broadcast ledger-update loop is duplicated across three files
  `fund_from_asset_lock.rs:114-148`, `transfer.rs:114-157`, and `withdrawal.rs:126-167` now carry near-identical loops: destructure `PlatformAddress::P2pkh`, build `PlatformP2PKHAddress`, apply the ownership guard, call `set_address_credit_balance`, reverse-scan the pool for an `address_index`, and push a `PlatformAddressBalanceEntry`. The bug this PR fixes was caused by exactly this kind of drift — the guard existed in `fund_from_asset_lock` and was missing from `transfer`/`withdrawal`. The PR description notes the `withdrawal` guard is added 'defensively for consistency', which is itself a symptom of the drift risk. Extracting a single helper on `ManagedPlatformAccount` (or in `platform_addresses`) that encapsulates the guard, index resolution, and changeset construction would make the next iteration of the invariant (e.g., observability, index-resolution error handling, nonce persistence) impossible to forget at any one site.
- [NITPICK] In `packages/rs-platform-wallet/src/wallet/platform_addresses/transfer.rs`:119-127: Foreign-address skip has no observability
  Both guards (`transfer.rs:125` and `withdrawal.rs:135`) drop foreign addresses with a bare `continue` and no log line. The original QA-010 bug surfaced as `No private key for address P2pkh(...)` deep in the sweep path during teardown — diagnosis took hours because the actual misbehavior was silent in the ledger-update layer. If a future regression elsewhere in the stack (e.g., gap-limit / pool-derivation race that hasn't yet recorded a derived address in `account.addresses`) misclassifies an owned address as foreign, the symptom is again `balance just doesn't update` with zero signal here. A single `tracing::debug!(wallet_id, account_index, %p2pkh, "skipping post-transition balance update for non-owned platform address")` inside each guard costs nothing at production log levels and makes the next analogous bug observable from logs alone. This is especially valuable in `withdrawal.rs` where the guard is documented as 'never expected to fire' — if it ever does, that's a signal worth surfacing.