Convert flat breakout families through family plans

[marcinpsk]

Parent

#73

What to build

Move discovery, preview, selection, validation, and execution of the existing flat-breakout-to-channelized conversion into the family module. Conversion must use the same family identity and intended naming decisions as installation and preview while preserving atomic rollback.

Acceptance criteria

• Conversion discovery uses installed family plans and accepts only complete, unambiguous flat breakout families.
• Candidate preview and dry-run reporting derive from immutable family and member facts.
• Existing selection and limit behavior remains compatible for foreground and background conversion operations.
• Conversion revalidates and locks the installed family before mutation.
• Conversion uses real NetBox model validation within the family transaction.
• A collision, stale plan, validation rejection, or channelization failure restores the complete original flat family.
• Successful conversion produces the intended parent, channel capacity, channel identifiers, relationships, and names.
• Conversion carries the base row's IP addresses and FHRP group assignments onto the new channel through model saves, not queryset updates, so every carried object is validated and recorded in the changelog like the rest of the family write.
• Conversion returns explicit outcomes that existing views and jobs can render without conversion tuples or mutable conflict lists.
• Scanning additional same-type modules does not introduce per-module template or family-discovery queries.
• Real PostgreSQL tests cover discovery, preview, selected conversion, dry run, successful conversion, collision, stale state, validation rollback, incomplete families, ambiguous families, unsupported topology, and the carried IP addresses and FHRP group assignments with their changelog entries.
• Existing conversion metadata and user-visible summaries remain compatible.

Implementation note

Discovery keeps identifying a family by its ch-0 row, so a family the module no longer carries
whole is still listed and refused with the row it is missing. Only complete, unambiguous families
are ever converted; an incomplete one is surfaced as blocked rather than hidden, because dropping it
from the Apply page would read as "nothing here to convert" and hide an edit the operator needs to
see. An ambiguous historical base is still dropped silently, unchanged from before.

Blocked by

• Build channelized families and reconcile deferred names #78

[marcinpsk]

Added one acceptance criterion and extended the test criterion.

_split_ch0_row() in engine.py moves the base row's carried objects with two queryset updates:

base.ip_addresses.all().update(assigned_object_id=channel.pk)
base.fhrp_group_assignments.all().update(interface_id=channel.pk)

A queryset update skips save(), so those two writes take no snapshot, fire no post-save signal and leave no changelog entry. An operator who converts a family sees the interface rows in the object history and the IP reassignment missing from it. Every other write in the conversion already goes through model saves inside the family transaction, so these two lines are the only part that leaves the ORM path.

The rewrite through family plans is the right place to close this: the executor that saves the parent and the channel should carry the addresses and the FHRP group assignments the same way.

#78 closed with #83, so the "Blocked by" entry is satisfied.