4.7 ltree migrations depend on the caller's search_path, breaking branch migrations

### NetBox Edition NetBox Community ### NetBox Version v4.7-Beta1 ### Python Version 3.12 ### Steps to Reproduce 1. Install NetBox 4.6.x with the netbox-branching plugin. 2. Create a branch, which provisions a copy of the data in its own PostgreSQL schema. 3. Upgrade NetBox to 4.7 and run python netbox/manage.py migrate against main. This succeeds. 4. Migrate the branch (the Migrate button on the branch, or MigrateBranchJob). Branching applies the same migration plan to the branch's schema, scoping search_path to that schema while each SQL operation runs, so a migration cannot reach into the main schema by accident. ### Expected Behavior The branch migrates and ends up with the same tree-path columns as main. More generally, the tree-path backfill added in 4.7 should not depend on how the search_path happens to be configured by whoever is running the migration - it should make the extension it needs available to itself, as the same migration's trigger installation already does. ### Observed Behavior The branch migration aborts and the branch is left in a failed state: `django.db.utils.ProgrammingError: type "ltree" does not exist` The three migrations that convert the hierarchical models from MPTT to ltree (dcim.0242_ltree_paths, tenancy.0025_ltree_paths, wireless.0021_ltree_paths) backfill each tree's path with SQL that names the ltree type and its operators bare. PostgreSQL resolves those names through search_path, so the step quietly requires the schema holding the extension to be visible to the caller. Branching is what surfaces it, but the dependency isn't specific to the plugin.