Fix(rds): handle MasterUserPassword in ModifyDBInstance

[ptanlam]

Summary

• ModifyDBInstance now correctly handles MasterUserPassword changes — previously the password was silently ignored
• Standalone DB instances now store _MasterUserPassword internally (matching how clusters already do), enabling password tracking and rotation
• New _rotate_instance_password helper rotates the password on real Docker-backed Postgres and MySQL containers

Problem

Applications calling ModifyDBInstance with MasterUserPassword expected the password to be updated (matching real AWS behavior), but MiniStack silently discarded the value. The field_map mapped "MasterUserPassword": None, and the loop skipped all None-mapped entries. Unlike DBParameterGroupName (also None-mapped but with dedicated handling below), there was no special code path for password changes. Additionally, instances never stored _MasterUserPassword at creation time, so there was no way to track the old password for rotation.

Changes

File	Change
ministack/services/rds.py	Store _MasterUserPassword on instances at creation; add _rotate_instance_password helper (supports both MySQL/MariaDB and PostgreSQL); handle MasterUserPassword in _modify_db_instance
tests/test_rds.py	New test_rds_modify_instance_password — creates instance, modifies password, asserts operation succeeds and other fields remain unchanged

Test plan

• New test_rds_modify_instance_password passes
• Existing test_rds_modify_cluster_password still passes
• All 46 RDS tests pass (45 existing + 1 new)
• Backward-compatible — _MasterUserPassword defaults to "password" for existing instances without the field

[Nahuel990]

Good work @ptanlam we'll be adding a modification related to the import of psycopg2 in the tests but excellent contribution. Welcome to Ministack!