Add netbox_rack_type module and rack_type option for netbox_rack

[jbartus]

New Behavior

• New netbox_rack_type module to create/update/delete rack types (dcim.rack-types, NetBox v4.1+).
• New rack_type option on netbox_rack to associate a rack with a type.
• New rack-types endpoint in nb_lookup.

Contrast to Current Behavior

Rack types can't be managed through the collection today (only via raw uri tasks). Includes a one-line fix in _convert_identical_keys() so the form_factor→type legacy conversion skips the rack_types endpoint, which uses form_factor natively; covered by a unit test.

Discussion: Benefits and Drawbacks

Fills a NetBox 4.1 gap. Backwards-compatible. Tested end-to-end against NetBox v4.5 plus unit/integration tests.

Changes to the Documentation

Adds the NB_RACK_TYPES autodata entry.

Proposed Release Note Entry

Added netbox_rack_type module, a rack_type option on netbox_rack, and a rack-types endpoint in nb_lookup.

Double Check

• I have read the comments and followed the CONTRIBUTING.md.
• I have explained my PR according to the information in the comments or in a linked issue.
• My PR targets the devel branch.

[ldrozdz93]

[claude]

Review Summary

LGTM — approving. netbox_rack_type faithfully mirrors the canonical netbox_device_type module, and the framework registration across the shared netbox_utils.py registries (API_APPS_ENDPOINTS, QUERY_TYPES, CONVERT_TO_ID, ENDPOINT_NAME_MAPPING, ALLOWED_QUERY_PARAMS, SLUG_REQUIRED) is complete and consistent with its siblings.

The _convert_identical_keys guard correctly preserves form_factor for the rack_types endpoint end-to-end: form_factor is not in CONVERT_KEYS, and run()'s rack block is gated on endpoint_name == "rack" (which is "rack_type" here), so neither path rewrites it. The new unit test pins both arms of the guard, the unit suite passes, and black is clean.

One non-blocking wording nit left inline on the new comment.

[ldrozdz93]

Approved, but there's a CI failure.