Also can't see how geometry nodes could cause this right now, but I also didn't manage to reproduce it without geometry nodes yet.
I was able to reproduce it in a new scene:

1. Duplicate the default cube (with alt+d so that the mesh is shared).
2. Add geometry nodes to the new cube. Add an Object Info node that loads the other cube and pass the geometry to the group output. Enable As Instance in the Object Info node.
3. Add a Normal Map node to the shader of the cubes and link it to the Normal input of the Principled BSDF.
4. Switch to material preview mode.
5. Try to enter edit mode.

With the file just try to enter edit mode on the selected object.

[EDIT: the bug I found below has been fixed separately]
I also ran into another issue in this setup, but it seems unrelated: P2566. This happens when I leave As Instance off, and when I exit edit mode on the other cube..
Looks like me->edit_mesh->mesh_eval_cage == me->edit_mesh->mesh_eval_cage->edit_mesh->mesh_eval_cage for some reason. This leads to infinite recursion.

After digging the issue, I came to a point where it seems that
const CustomData *cd_ldata = mesh_cd_ldata_get_from_mesh(me_final); in mesh_cd_calc_used_gpu_layers
does not contains the same layers as
CustomData *cd_ldata = (mr->extract_type == MR_EXTRACT_BMESH) ? &mr->bm->ldata : &mr->me->ldata; in extract_tan_ex_init
which makes tangent layer generation to fail.

In BKE_mesh_calc_loop_tangent_step_0, DM_TANGENT_MASK_ORCO is only added to the tangent mask if there is no uv layer. mesh_cd_calc_used_gpu_layers does not see any UVs, thus query only orco tangent layer. But BKE_mesh_calc_loop_tangent_step_0 will not create the tangent layer since there is a valid UV layer to query a tangent layer from, but it does not match any requested tangent layer name (because only orco was needed).

I tried (P2572) to make tangent orco generation work even in the presence of valid UV layer but couldn't make it work (CustomData_get_named_layer_index(loopdata_out, CD_TANGENT, "") still returns -1 even after CustomData_add_layer_named(loopdata_out, CD_TANGENT, CD_CALLOC, NULL, (int)loopdata_out_len, "");). It not help because the rest of the generation code also assumes the same thing as BKE_mesh_calc_loop_tangent_step_0 (that orco is only here as fallback).

To me all of this is quite fragile since this means everything needs to have the same behavior and be in sync for things to never fail.

The real fix is likely to fix the premise of the issue, which is that cd_ldata differs between eval and request. But I wouldn't know how to fix that.

Based one what @Clément Foucault (fclem) said and by doing some more digging I managed to reproduce the issue in a more controlled environment (and without geometry nodes, but with a small code change).

New steps to reproduce:

1. Apply P2574. This adds a line to the array modifier (could have picked most modifiers) that removes the uv map on the mesh.
2. Duplicate the default cube with alt+d (so that the mesh is shared).
3. Add the array modifier to the new cube.
4. Add a Normal Map node to the shader of the cubes and link it to the Normal input of the Principled BSDF node.
5. Switch to material preview mode.
6. Try to enter edit mode on the cube that has the modifier.

With the file just apply P2574 and try to enter edit mode on the selected object.

This may be related to the more fundamental issue that when an object with a shared mesh goes into edit mode, all objects with the same mesh will show the evaluated mesh of the object that went to edit mode:

The issue had nothing to do with the Object Info node in my previous post. It was just important the geometry nodes outputs an empty mesh that does not contain the uv map. This should be perfectly legal behavior.