This surfaced while I was trying to make use of dnglab in one of my own projects. Pinpointed with AI assistance while trying to figure out differences between files created by dnglab and those created with Adobe tools.

Describe the bug
Converting a Canon EOS M3 CR2 (EF-M 18-55mm kit lens) to DNG produces no lens metadata
(LensModel, LensInfo), although the lens is present in rawler's lens database.

The camera writes EXIF LensModel as EF-M18-55mm f/3.5-5.6 IS STM (no space after
"EF-M"); rawler/data/lenses/ef_mount/canon.toml has
model = "EF-M 18-55mm f/3.5-5.6 IS STM". CR2Decoder::get_lens_description() passes
the EXIF string to LensResolver::with_lens_keyname(...), the comparison is exact, so
resolution fails on the whitespace difference alone. (The makernote lens-ID for this
lens is ambiguous — "Canon EF-M 18-55mm f/3.5-5.6 IS STM or Tamron Lens" — so the
keyname is the decisive signal.)

To Reproduce

1. exiftool -LensModel IMG_8330.CR2 → EF-M18-55mm f/3.5-5.6 IS STM
2. dnglab convert IMG_8330.CR2 out.dng
3. exiftool -LensModel -LensInfo out.dng → both tags absent

Expected behavior
The lens resolves against the existing DB entry, e.g. by collapsing whitespace on both
sides of the keyname comparison. Camera firmwares are inconsistent about spacing in lens
names; both spellings occur in the wild.

Desktop (please complete the following information):

• OS: Arch Linux
• dnglab: 0.7.2 and current main (84ff151), same behavior

Additional context
Not a duplicate of #498/#494 — those concern downstream apps failing to auto-detect from
lens tags dnglab wrote correctly. Here the whitespace fragility is in dnglab's own
resolver and no lens tags are written at all. Sample CR2 available on request.