Fix iter_notes crash on GNU build-ID notes in core dumps

[apoorva-01]

Core dumps can carry a GNU build-ID note (type 3, name GNU). But in an ET_CORE file type 3 means NT_PRPSINFO, so iter_notes() reads the short build ID as a 124-byte prpsinfo struct and blows up with ELFParseError. readelf handles the same file fine.

Fix: if a note is named GNU in a core file, resolve its type against the generic GNU enum instead. Only touches core files.

Open question for you: the broader fix is to decode n_type as a raw int and pick the enum from n_name in iter_notes. More general, but it changes the shared struct, so I kept this contained. Your call.

Test builds a tiny ET_CORE ELF with a build-ID note. Fails before, passes after. Suite green, ruff clean.

Closes #656.

[sevaa]

Never had to deal with coredumps myself, but the logic looks sensible. We don't have a lot of coredumps in the corpus though, do we?

[apoorva-01]

Yeah, just the three core_linux* fixtures. That's why I built the ET_CORE file inline in the test instead of committing another binary. Easy to point at a real coredump too if you'd rather have one in the corpus.

[eliben]

While the logic looks ok, the whole issue feels extremely niche to me. It would be nicer to see a more general solution here, as well as a couple of representative core files committed in that actual comparison tests could run on.

[apoorva-01]

I'll switch to the general version: resolve the type from n_name (GNU notes use GNU types, CORE notes use core types) instead of keying off e_type. That fixes the reverse case too.

For fixtures: what do you prefer?
I can generate a small real coredump with a build-id note and wire it into the readelf comparison tests, or use a specific core if you have one in mind

[eliben]

Generating a small real coredump is fine - but please include clear instructions on how to reproduce it (e.g. a simple C file, the gcc command to create the binary, and the execution steps).