Fix API circuit type validation rejecting valid circuitTypes ids - #4643

Part of #4642 (context/overview for a set of 4 related API fixes).

Bug

POST/PATCH to /api/{app_id}/circuits/ reject every request that includes a type,
even a valid one:

curl -s -k -X POST --header "token: …" --header "Content-Type: application/json" \
  --data '{"circuit_id": "Test7", "provider": 12, "type": 24, "capacity": "1T", "status": "Active"}' \
  https://host/api/my_app/circuits/

{"code": 400, "success": false, "message": "Invalid circuit type", "time": 0.004}

Same result on PATCH:

curl -s -k -X PATCH --header "token: …" --header "Content-Type: application/json" \
  --data '{"circuit_id": "TN2-NGD-LV3-001", "provider": 12, "type": 44, "capacity": "1T", "status": "Active"}' \
  https://host/api/my_app/circuits/52293/

{"code": 400, "success": false, "message": "Invalid circuit type", "time": 0.003}

type fails no matter what's supplied - a numeric id, a string id, or the type's name all
produce the same error. A PATCH that omits type entirely (e.g. only capacity) works
fine, which was the tell.

Root cause

validate_circuit_type() treats circuits.type as a legacy MySQL enum(...) column and
tries to parse the allowed values out of getFieldInfo("circuits", "type")->Type. type
was migrated to a plain int(10) unsigned foreign key into the circuitTypes lookup table
some time ago, so getFieldInfo() now returns "int(10) unsigned" as the Type string -
never anything resembling a real type id - and the in_array() check fails unconditionally.

Fix

Validate type against real circuitTypes rows instead, mirroring the already-correct
pattern already used by the non-API UI in app/admin/circuits/edit-circuit-submit.php
(fetch real rows via Tools->fetch_all_objects("circuitTypes", "ctname"), check the
submitted id against real ids). The "no type supplied on create" fallback now resolves to
the circuitTypes row named Default's actual numeric id, instead of assigning the
literal string "Default" to a now-numeric column.

Fixes #4038
Fixes #3148

Tested with

Verified: the exact failing POST/PATCH payloads above now succeed; a genuinely invalid
type (e.g. 999) is still correctly rejected; an invalid provider is still correctly
rejected; the previously-working capacity-only PATCH still works. Customers/Locations
regression-checked, unaffected.

Tested against PHP 8.2, 8.3, and 8.4 (the full range develop's README lists as
supported) - lint clean and all scenarios passing on each, no new entries in the PHP error
log.