Upgrade MUI version

[pawelperek-da]

Fixes #2733

Pull Request Checklist

Cluster Testing

• If a cluster test is required, comment /cluster_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
• If a hard-migration test is required (from the latest release), comment /hdm_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.

PR Guidelines

• Include any change that might be observable by our partners or affect their deployment in the release notes.
• Specify fixed issues with Fixes #n, and mention issues worked on using #n
• Include a screenshot for frontend-related PRs - see README or use your favorite screenshot tool

Merge Guidelines

• Make the git commit message look sensible when squash-merging on GitHub (most likely: just copy your PR description).

[pawelperek-da]

@fayi-da apparently that’s how we fill date fields in unit tests now 🙂
The await user.type call leaves the field in an Invalid Date state, which messes up the tests.
Kind of funny, because when I was writing my first UI tests, I remember fireEvent.change not working quite right

[pawelperek-da]

@fayi-da for some reason, toBeDefined was giving me both false positives and false negatives (it seems like screen.queryByText returns a DOM-like Null instead of a standard JS null). Switching to toBeInTheDocument fixed the existing test errors and revealed some new ones (e.g. apps/sv/frontend/src/components/forms/SetAmuletConfigRulesForm.tsx). I’d propose we use toBeInTheDocument from now on

[pawelperek-da]

MUI’s <Select /> doesn’t support a placeholder prop, so it doesn’t do anything (see PR #1626), and in v7 it actually throws an error. If we want to match the Figma designs, we’ll need to hack in a placeholder manually.

[pawelperek-da]

Done with https://mui.com/material-ui/migration/upgrade-to-grid-v2/

[pawelperek-da]

Context: In MUI v7, the DatePickers introduced a new “accessible” structure. Instead of a simple <input />, the picker is now composed of multiple <div> elements with tab-selectable slots (year, month, day, etc.), plus a read-only <input /> managed by those <div>s.

While this approach is great for UX and accessibility, it’s absolutely horrible for integration testing. I’ve tried several methods to programmatically fill these pickers, including:

1. sendKeys to the read-only <input /> (current approach)
2. sendKeys to the parent <div> that manages the DatePicker
3. sendKeys directly to individual slot <div>s (fails due to remounting)
4. sendKeys to slot <div>s while searching for the next slot after each input
5. js.executeScript to focus/click the managing <div> and then sendKeys (works in the browser but not in tests)
6. js.executeScript to set the value directly in the script

...and several other variations, but none of them worked reliably.

Given that, I propose we keep using the pre-v7 non-accessible structure for now. Unfortunately it’s soft-deprecated and while it doesn’t raise warnings yet, it's planned for removal in v9, so I hope either it will be fixed until then or we will figure our some trick to fill it