fix: JPEG detection fails on files with trailing data (Motion Photos)

[tetsugakusha256]

detect_format() in magic.lua has a check that requires FFD9 (JPEG EOI) to
be the literal last 2 bytes of the file. That breaks on any JPEG that has
data appended after the actual image — Google/Samsung Motion Photos being
the common case (JPEG + embedded MP4 + trailer footer).

For these files the real EOI is somewhere in the middle, so
has_jpeg_end_signature() returns false and detect_format() returns nil for
the whole file, even though it's a perfectly valid JPEG. ImageMagick has
no problem with these files (tested manually with identify/convert), it
just stops reading at EOI like it's supposed to.

I don't think this check is worth keeping — no other format in the table
gets this kind of extra validation, and detect_format() has no fallback
to the identify-based path used elsewhere in the plugin, so this was a
silent permanent failure rather than just a perf hit.

Removed the EOI check and the now-unused has_jpeg_end_signature function.

Tested:

• Motion Photo JPEGs now detected/rendered correctly
• truncated JPEGs still fail sensibly downstream - partial render if
  there's enough data, clean identify error ("insufficient image data")
  if not

[Eurekaimer]

I independently reproduced this on current master, and it seems to affect more than just Motion Photos.

In one of my image repositories, 33 out of 56 regular JPEGs have trailing data after a valid FF D9 EOI. They decode correctly with ImageMagick, Pillow, browsers, and Obsidian, but current image.nvim rejects them because the EOI is not the final two bytes.

Removing this check also fixes rendering for these images on my setup.

So +1 for this fix. It might also be useful to add a regression test with a valid JPEG plus some trailing data to prevent this from coming back.