Data Migration & UAT Fixes

[oakdbca]

• Rework some of the CS adapter and handler to match other migration structures
• Implement any missing transformations to prepare for dev data verification

Bug fixes for:

13979 | CS Delisting change 3/5: introduce a condition (based on Change Type) to alter the final actions displayed
13980 | CS Delisting change 4/5: validation required when Change Type = DeList is selected

[sentry]

Bug: The migration silently creates ConservationStatus records with a null species_id if a Taxonomy record lacks an associated Species, bypassing model-level safeguards by using bulk_create().
_{Severity: MEDIUM}

Suggested Fix

Before creating the ConservationStatus object, check if species_pk is None after the lookup. If it is, log an error and continue to the next row. This will prevent the creation of inconsistent records and restore the explicit validation behavior of the previous code.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: boranga/components/data_migration/handlers/conservation_status.py#L267-L279

Potential issue: The data migration handler for `ConservationStatus` resolves species
via a `taxonomy_id`. If a `taxonomy_id` from legacy data exists but has no corresponding
`Species` record, the `tax_to_species_pk_map.get()` call returns `None`. This `None`
value is then assigned to `species_pk` and used in the `ConservationStatus` object
creation. Because the handler uses `bulk_create()`, it bypasses the model's `save()`
method and its `assign_or_create_species()` safeguard. This results in the silent
creation of `ConservationStatus` records with a valid `species_taxonomy_id` but a `null`
`species_id`, leading to data inconsistency. The previous implementation would have
logged an error and skipped such records.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[xzzy]

Sensitivity check Completed