docs(Order Configs): correct flow projection + align example with fleetops

[roncodes]

Summary

The actual /v1/order-configs/{id} response returns flow as an object keyed by activity code, with each Activity carrying its full editable shape (key, code, color, logic, events, actions, options, entities, sequence, activities, internalId, pod_method, require_pod, etc.). The previous docs framed it as a projected array and omitted the graph-link (activities) and editor wiring — exactly the fields integrators need to walk the workflow.

What's wrong today

1. flow shape is wrong — documented as an array of objects; actually returned as an object map keyed by activity code.
2. Missing fields — the previous doc only listed code, status, details, color, complete, pod_method, require_pod. The real response also includes key, logic, events, actions, options, entities, sequence, activities (child codes — the graph edge list), and internalId.
3. pod_method valid values weren't enumerated (scan | signature | photo | null per config/fleetops.php).
4. id prefix wrong — HasPublicId builds {publicIdType}_{hashid} and OrderConfig::$publicIdType = 'order_config', so the real prefix is order_config_, not ordercfg_.
5. version typed as integer — DB column is string (varchar), and FleetOps::createTransportConfig seeds '0.0.1'.
6. status description says e.g. \active`but newly created configs default toprivateperOrderConfig::boot()`.
7. Example payload uses fake colors, empty details, null pod_method, and empty tags — none of which match FleetOps::createTransportConfig's default seed.

What this PR changes

• flow is typed object and described as the activity graph keyed by canonical activity code. Lists the well-known codes (created, dispatched, started, enroute, completed, canceled), notes that map order is insertion order — not graph progression — and points consumers at each activity's activities array for traversal.
• Every activity field is now documented as a nested <Param>: key, code, status, details, color, sequence, complete, activities, pod_method, require_pod, logic, events, actions, options, entities, internalId.
• logic carries the gate shape (type + conditions) and supported operators (exists, in/has, notIn/doesntHave, contains, beginsWith, endsWith, plus standard comparisons), sourced from Flow/Logic.php and Flow/Condition.php.
• pod_method enumerates scan | signature | photo | null (from config/fleetops.php).
• Corrects id prefix → order_config_, version → string semver, status default → private.
• Example replaced with the actual default-seeded Fleet-Ops transport config response.

Validation

node scripts/validate-collections.js
# Validated 5 Postman Native Git collections and 3 environments.

The fleetbase.io doc generator also produces clean MDX from this YAML (verified end-to-end with pnpm run build). The multi-line <Param> indent fix landing in fleetbase.io#25 is required for the new nested logic description block to render.

🤖 Generated with Claude Code