Replace IP Allowlisting with Password-Protected Maintenance Mode

### User story

As an administrator of a Shopware 6 store,
I want to enable maintenance mode with password protection instead of relying on IP allowlisting,
So that I can securely and easily grant access during maintenance without being affected by dynamic IP changes.

**Problem with Current Behavior**

- Fragile Setup in Dynamic Environments: Many admins work in environments where IPs change frequently (e.g. mobile networks, home offices with dynamic IPs).
- Operational Overhead: Updating the list of allowed IPs is cumbersome, error-prone, and not easily accessible through the UI.
- Limited Scalability: Collaborating with multiple developers, QA teams, or agencies requires coordination and manual updates to IP lists.

Benefits
- Scales Better: One password can enable access for multiple collaborators instantly.
- More Robust: Not sensitive to changes in IP, VPN use, or mobile setups.
- Better caching: Its easier to cache the whole store/maintenance page and only bypass the cache if the authentication cookie is present
- Faster Setup: Easier and more intuitive for non-technical users; no need to retrieve or whitelist IP addresses manually.

### Acceptance criteria

- Admins can set a shared access password for maintenance mode via the admin panel or .env file.
- Visitors are shown a maintenance screen unless they enter the correct password.
- Access is granted per session after entering the correct password, with cookie/session-based persistence.
- Admins can revoke/reset the access password anytime.

### Definition of Done

- [ ] Fulfills all acceptance criteria defined during discovery.
- [ ] Integration/E2E testing in staging is done.
- [ ] All integration/E2E/unit tests passing; all critical or high-priority bugs are resolved.
- [ ] Fulfills compliance, performance, security, and cloud-readiness needs.
- [ ] Observability—includes monitoring, alerting, and logging; incident response handbooks updated.
- [ ] Documentation—developer docs are written or updated, including information on how the feature or change is adopted and tested. If new functionality, end user documentation is written or updated.
- [ ] (conditional) All new API endpoints have a defined API schema.
- [ ] (conditional) If the change affects the Storefront, it has been tested in the latest three versions of Firefox, Chrome, Edge, IE11, and Safari, as well as the different viewports and devices (Desktop / Tablet / Mobile).
- [ ] (conditional) If the change affects the Administration, it has been tested in current versions of Firefox, Chrome, and Edge.
- [ ] (conditional) Functionality that includes new API routes are callable via the Store-API (/store-api/[version]/).
- [ ] (conditional) If a new Admin module is created, the access control layer is provided, and permissions can be managed via the Users & Permissions module.
- [ ] (conditional) If a new UI input field or interactive element is introduced, the ACL wrapper is added.
- [ ] (conditional) Performance testing done if the change has a high performance impact, such as affecting scalability, load balancing, or query optimization.