Normalize order customer polymorphic type

[roncodes]

Summary

Adds a FleetOps-side guard for order creation so customer polymorphic types are always persisted as concrete FleetOps model classes instead of the abstract customer type. This prevents order creation from failing during created webhook payload generation when the client submits customer_type as fleet-ops:customer.

Root Cause

The order create request can include a selected customer relationship whose Ember model is the abstract customer model while the actual record is a contact or vendor. When customer_type arrives as fleet-ops:customer, FleetOps converts that polymorphic type into Fleetbase FleetOps Models Customer. That PHP model does not exist. The order insert can complete, but the created model event builds the webhook payload, touches the Order customer morph relation, and Laravel throws Class Fleetbase FleetOps Models Customer not found.

This PR complements the fleetops-data serializer fix by making FleetOps resilient to stale or generic internal order payloads.

Changes

• Adds a dedicated order form customer selection action in addon/components/order/form/details.js.
• Updates addon/components/order/form/details.hbs so the customer selector calls that action instead of only mutating customer and customer_uuid independently.
• The action sets customer, customer_uuid, and customer_type together, preferring the selected model uuid and using the selected model customer_type to emit fleet-ops:contact or fleet-ops:vendor.
• Adds normalizeCustomerType to the internal v1 OrderController create path.
• Before persistence, normalizeCustomerType resolves the submitted customer_uuid against contacts and vendors for the active company and replaces customer_type with the concrete model class resolved from the matching table.

Behavior Before

A payload like customer_uuid b1641199-12e4-4c1e-8459-9f2dd9101c47 with customer_type fleet-ops:customer could persist an invalid morph class. When the created webhook payload accessed this customer relation, Eloquent attempted to instantiate Fleetbase FleetOps Models Customer and crashed.

Behavior After

The order form submits the concrete customer type when a customer is selected. The backend also normalizes customer_type from customer_uuid before saving, so even a stale or generic internal payload is corrected to Contact or Vendor before the order model fires created lifecycle/webhook logic.

Verification

• php -l server/src/Http/Controllers/Internal/v1/OrderController.php
• ./node_modules/.bin/prettier --check addon/components/order/form/details.js addon/components/order/form/details.hbs
• ./node_modules/.bin/eslint addon/components/order/form/details.js
• git diff --check -- addon/components/order/form/details.js addon/components/order/form/details.hbs server/src/Http/Controllers/Internal/v1/OrderController.php

Notes

This branch intentionally commits only the order customer-type normalization files. The local worktree contains unrelated pre-existing changes in workflow, package, route form, and payments files; those were left uncommitted and out of this PR.