Occurrence-row history for locality and species occurrence lists

[karilint]

Goal

Show history for occurrence rows in locality/species occurrence lists, similar to the field history icon from #1183 but scoped to a list row entry.

Background

Occurrence rows (now_ls) are relation-like records between locality and species. Users need a quick way to see when an occurrence entry was created, removed, or otherwise logged without first opening the full occurrence detail page.

Proposed behavior

Add a small history icon in front of or near each occurrence row in read mode. Opening it should show update metadata and row-level changes, including date, editor, coordinator, comment, references, action, and changed values where available.

Technical notes

This is similar to generic entry history, but occurrences are more complex than simple locality-owned relations:

• now_ls update logs can be tied to both locality update ids (luid) and species update ids (suid).
• The occurrence detail endpoint already builds richer merged update history in now_oau.
• Locality/species list pages may need backend payload enrichment or a shared helper so row history is complete for both locality-originated and species-originated occurrence updates.

Consider whether the solution can share UI with a generic entry-history popover while using occurrence-specific backend matching/enrichment for now_ls.

[karilint]

Coding task: add occurrence-row entry history for locality and species occurrence lists. I will inspect the existing occurrence detail history enrichment, reuse the shared entry-history popover where possible, and add any needed backend/frontend wiring so now_ls row history includes locality/species update metadata, comments, references, actions, and changed values.

[karilint]

Implemented in draft PR #1195. The root cause was that occurrence detail pages already built merged now_oau history from now_ls log rows tied to locality (luid) and species (suid) updates, but locality/species occurrence list rows did not receive that enriched history. The change batches occurrence-history enrichment for list rows and wires the shared entry-history popover into both occurrence list tabs.

[karilint]

Manual test checklist for PR #1195:

• Open a locality with occurrence rows that have update history.
• Go to the locality Occurrences tab in read mode.
• Verify occurrence rows with matching now_ls history show a history icon.
• Click the icon and confirm the popover shows date, editor, coordinator, action, table, before/after values, comments, and references where available.
• Confirm clicking the history icon does not navigate to the occurrence detail page.
• Open a species with locality/occurrence rows that have update history.
• Go to the species Occurrences tab in read mode and repeat the same history popover checks.
• Open an occurrence detail page for the same (lid, species_id) and confirm the row popover history is consistent with the occurrence update history shown there.

[karilint]

Follow-up for the now_ls duplicate history report: entry history now groups all matching audit log rows from the same update container into a single popup card. This keeps field-level history unchanged, but occurrence rows with separate lid/species_id audit rows now show as one history event with the changed values listed together.

Manual test checklist:

• Open a locality/species occurrence row with now_ls update history for both lid and species_id.
• Click the row history icon.
• Confirm the popup shows one history card for the update event, not duplicate cards.
• Confirm the grouped card still lists the changed fields and references/comment.

[karilint]

Second follow-up for the now_ls duplicate history popup: the popup now also deduplicates identical grouped entry-history cards. This covers cases where the same occurrence update container is discovered more than once, so a row such as occurrence 29563/29401 should show one Add history card with both lid and species_id changes.

Manual test checklist:

• Open occurrence 29563/29401 history, or another now_ls row with the duplicated Add entry.
• Confirm only one Add card appears for the identical date/editor/coordinator/table/change/reference set.
• Confirm separate genuinely different update events still appear separately.