spiram: Fix corrupting 1 kB of noinit data in spiram in 2T mode (IDFGH-11242)

[jovermann]

The function psram_2t_mode_check() in esp_psram_impl_quad.c overwrites the first kilobyte of every megabyte with 0xff upon startup which may overwrite noinit data which should be preserved over reboots.

This patch fixes this by saving/restoring the tested memory.

The test size has been reduced from 41024 bytes to 4512 bytes just to keep the stack usage of the fuction within resonable limits (was 2048 bytes, now 1536 bytes).

Fixes #12395
(IDFGH-11231)

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Overmann, Johannes seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

	Messages
📖	Good Job! All checks are passing!

---

👋 Welcome jovermann, thank you for your first contribution to espressif/esp-idf project!

📘 Please check Contributions Guide for the contribution checklist, information regarding code and documentation style, testing and other topics.

🖊️ Please also make sure you have read and signed the Contributor License Agreement for espressif/esp-idf project.

Pull request review and merge process you can expect

Espressif develops the ESP-IDF project in an internal repository (Gitlab). We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

1. An internal issue has been created for the PR, we assign it to the relevant engineer
2. They review the PR and either approve it or ask you for changes or clarifications
3. Once the Github PR is approved, we synchronize it into our internal git repository
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing
   • At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the master branch
6. On next sync from the internal git repository merged change will appear in this public Github repository

---

Generated by 🚫 dangerJS against 913e0be