Generate cuopt_routing.proto and VRP mapper via field_registry codegen

[ramakrishnap-nv]

Summary

Bring VRP under the gRPC field_registry codegen so cpp/src/grpc/cuopt_routing.proto and the proto ↔ cpu_routing_problem_t conversion are generated (like the math-opt LP/MIP protos), replacing the hand-authored proto and the ~377-line hand-written cpp/src/grpc/grpc_routing_problem_mapper.cpp.

Follow-up to #1597, where this was intentionally deferred to keep that PR focused/landable (see thread).

Scope

• Model the routing messages in field_registry.yaml: RoutingProblem, RoutingSolverSettings, RoutingSolution, and sub-messages (CostMatrix, CapacityDimension, VehicleBreak/PerVehicleBreaks/UniformBreakDimension, MatchEntry, PrecedenceEntry, ServiceTimeEntry, RoutingObjectiveFunction, InitialSolution).
• Generate cuopt_routing.proto from the registry and delete the hand-authored file.
• Generate the proto ↔ cpu_routing_problem_t conversion and delete grpc_routing_problem_mapper.cpp.
• Extend ci/verify_grpc_codegen.sh coverage to the routing proto/mapper.

Known blockers / considerations

• The routing sub-messages fit the existing repeated_messages mechanism (cf. quadratic_constraints in field_registry.yaml).
• No proto3 map<> support in generate_conversions.py yet — RoutingSolution.objective_values is map<int32, double>. Either add map support to the generator or model it as parallel repeated key/value arrays.
• The current mapper has bespoke logic that doesn't fully fit the array-id chunked model: cost-matrix grouping by vehicle_type, capacity dimensions (name + demand + capacity), per-vehicle service times (vehicle_id = -1 default), PDP pickup/delivery indices, breaks, vehicle/order matching, precedence, and initial solutions.

🤖 Generated with Claude Code

[ramakrishnap-nv]

Expanding scope from #1597 review (rg20). In addition to generating cuopt_routing.proto, the follow-up should also:

• Generate the proto↔cpu_routing_problem_t mapper (grpc_routing_problem_mapper.cpp) so a newly added array can't be wired in one place and silently missed in the other — the current hand-written mapper is error-prone in exactly this way (thread).
• Remove the host-struct population boilerplate on the cpu_routing_problem.cu side, which is the same class of hand-written mapping (thread).
• Add round-trip + coverage tests for the generated mapper (problem → proto → problem), the C++ analogue of the existing Python test_routing_grpc_serialization setter-coverage guard (thread).
• Consider unifying/generating the per-domain Python gRPC clients (cuopt.grpc.linear_programming / cuopt.grpc.routing) so that layer stops being hand-maintained (thread).