fix(acl): carry the ACL user whitelist through user upserts

[yyqdbngt]

Summary

• map whiteRemoteAddress in MybatisPlusAclRepository.toUserEntity so the generic user upsert path persists the whitelist
• add capture-based regression tests for saveUser and replaceUser

Why

toUserVO reads white_remote_address from the row, but toUserEntity never wrote it back: every upsert through the generic saveUser/replaceUser path silently dropped the whitelist carried on the VO. The plain-access endpoint worked around this by building its entity manually, but any caller of the generic upsert with a set whitelist lost it without an error. Existing updateUser behavior is unchanged because the merged VO carries a null whitelist and MyBatis-Plus omits null fields from updateById.

Testing

• cd server && mvn -q -Dtest=MybatisPlusAclRepositoryTest test — all tests pass, including the new saveUserShouldPersistTheWhiteRemoteAddress and replaceUserShouldCarryTheWhiteRemoteAddressIntoTheUpdate
• cd server && mvn -q -Dtest=AclServiceTest test — all tests pass (regression for the update flow)

[RockteMQ-AI]

Summary

Carries the ACL user whitelist through user upsert operations so it is not silently dropped. Good bug fix — prevents ACL configuration loss during user updates.

Findings

• [Info] The fix correctly preserves the whitelist field during the upsert path.

Suggestions

No blocking issues. Test coverage verifies the whitelist survives the round-trip.

---

Automated review by github-manager-bot