Read EXIF with a parser somebody maintains

[cerede2000]

P3-10 of phase 3 (see #373). Stacked on #433–#441.

exifr was last published in 2022

It is the one dependency in the image whose job is to open a file somebody else wrote,
using code nobody maintains any more — and the metadata route loads it lazily, in a
try/catch, which reads like somebody was not sure of it either:

let exifr = null;
// Optional: try to require exifr only when route is hit

exif-reader replaces it: maintained alongside sharp, and it does nothing but walk a
TIFF-shaped block with a bounds check on every read. The block needs no file access of its
own — sharp already opens the image to report its dimensions and hands the raw EXIF block
back with them — so a photograph's details come from one pass instead of two, and exifr
leaves backend/package.json.

What the block is read for

utils/exifDetails.js: when the picture was taken, the camera and lens, the exposure, the
orientation, the place. Its own file because the metadata route is about what kind of
thing a file is, and this is about what a photograph says of itself.

Checks

• exif-details.test.js, 20 tests over the reading itself: a block that is not EXIF,
  a truncated one, dates in the three shapes cameras write them, a rational that divides
  by zero, coordinates in both hemispheres. Making the reader answer nothing turns six
  of them red.
• metadata.test.js, 13 tests through the route.
• Whole backend suite: 2 509 passed, 2 failed — the two that fail on main alone.
• Formatting unchanged; frontend builds; backend loads with exifr gone.

capabilities.js, documentText.js and pdfTextExtract.js were in this batch at first
and are not any more: probing which optional tools the machine has, and reading a
document's text, are their own ground, and bringing them here turned three of main's own
tests red.