Update Gem Identification

PATCH /api/v1/gems/{gem_id}/identification (LNK-IDFIX)

The owner overrules the scan's species, and the valuation follows.

Two things happen, in this order and for a reason. First the correction is written: species, title, and the preserved record of what we said. Then the gem is re-priced against the corrected species. If the re-pricing fails or finds no market data, the CORRECTION STILL STANDS and the gem comes back with no estimate — never with the price that belonged to the rejected identification. A moissanite price under the heading "Blue Zircon" reads as though we priced the corrected stone, and that is the exact failure this endpoint exists to undo.

Re-pricing re-runs the valuation only: comps, macro index, metal melt, sanity cap. No vision, no LLM, no image re-read, and so no scan quota is charged. A correction must never cost the owner a scan for telling us we were wrong.

Species outside our taxonomy are accepted, flagged off_catalog, and generally come back revalued: false — we hold no market series for them. Refusing them would mean refusing exactly the corrections most worth having.

Owner-only, resolved the same way as PATCH /{gem_id}/records: user_id when authenticated OR device_id via X-Device-Id, with the owner filter inside the query so a foreign gem 404s without leaking that it exists.