EEPROM on the ESP32 doesn't work like you would expect. It uses the SDK's "Non-Volatile Ram" storage system to store the data within the nvs partition. This works through a system of "Key / Value" pairs, and the data is stored as a "BLOB" (Binary Large OBject) for the key eeprom in the namespace eeprom.
Quite what the internal layout of the data within the partition itself is I have no clue (the SDK is closed source), but it won't just have your string located at the start of the partition - it will be at the start of the BLOB, wherever that happens to be in the partition.
The eeprom partition is no longer used. It's just wasted space.
Can this flash-detection be trusted or does it simply fail because I try to flash 8MB to a 4MB ESP32?
I can't comment on that I'm afraid. I would have thought it would look at the chip's JEDEC data, but it may just look at the partition table information instead.
What is supposed to happen if I created a partition table that exceeds the flash memory size?
Probably not a lot, since much of the partition table refers to data storage, or a (presently) unused OTA partition.
When you compile your code you're only compiling it for the partition in which it will reside (app0 for example). When you upload the code you are only uploading to that partition. Anything outside that range is irrelevant to the compilation / uploading.
When I put a partition table at an offset of 10M the build process still doesn't fail (is that what should happen?).
As I mentioned, it won't care. The partition will not be accessible, since it doesn't actually exist, but it's just an entry in a table. The compiler doesn't know or care what it is.