Make the inventory lot barcode findable

[mherman22]

Stack (review bottom-up):

1. feat(inventory): add a readable code to an inventory item #4015 Add a readable code to an inventory item
2. feat(inventory): put inventory lots in the same storage system samples already use #4016 Put inventory lots in the same storage system samples already use
3. feat(inventory): add a Reports tab with CSV, PDF and XLSX export #4017 Add a Reports tab with CSV, PDF and XLSX export
4. feat(inventory): show the item code in the catalog and item form #4018 Show the item code in the catalog and item form
5. fix(inventory): fix what review and hands-on testing turned up #4019 Fix what review and hands-on testing turned up
6. This PR — Make the inventory lot barcode findable

Stacked on #4019. Two commits are new here.

The Barcode field on the lot modal was write-only: you could type a value and
it was stored and enforced unique, but nothing ever read it back.
InventoryLotDAO.getByBarcode was written and had no callers at all, the
barcode was not a table column, and the dashboard search matched only lot
number and item name. Nothing in the UI said whether the field meant the
manufacturer's barcode or an internal one, which matters because the UNIQUE
constraint is only correct for the internal reading — a GTIN is shared by every
lot of a product.

The barcode is now the lab's own label and the system mints it. Leave the field
blank and the service generates one from the item code and lot number
(TEST_REAGENT_A_LOT_2025_001), so a human can still identify the lot when the
printed label is damaged; supply one explicitly and it is normalised instead.
This reuses CodeGenerator and mirrors InventoryItemServiceImpl.resolveCode
exactly, including collision suffixing and a localized duplicate error rather
than a raw constraint violation. The field locks after save the same way the
item code does, since printed labels have to keep working. Lookup is wired
through to GET /rest/inventory/lots/barcode/{barcode} and the dashboard
search now matches on barcode.

The dashboard tests turned up a separate bug worth a look: rows were matched to
lots by array index, so with a sortable table any row action — move, dispose,
QC — could act on a different lot than the one clicked. Now matched by id, with
a regression test that fails against the old lookup.

Deliberately not here: scan-to-act on the dashboard, lot label printing, and
GS1 parsing to auto-fill lot number and expiry from a manufacturer barcode.
Each is a feature in its own right and depends on this being wired up first.

[mherman22]

https://uwdigi.atlassian.net/browse/OGC-1176