Type stability: per-type service construction dynamic-dispatches on abstract flattened Vectors

[rodrigomha]

The per-type ServiceModel refactor (#206) introduced a few build-time type instabilities in reserve/service construction: iterating Vectors whose element type has widened to an abstract ancestor forces dynamic dispatch. None affect solve-time performance, so they were deferred out of #206.

Sites (POM)

1. services_models/services_constructor.jl — get_contributing_devices(model, service_name) flattens across device types, so its element type widens to an abstract ancestor when a service has more than one contributing device type; the downstream construct_service! builders then dynamic-dispatch per device.
   Fix: iterate get_contributing_devices_map(model, name) (Dict{DataType, Vector} — concretely typed groups) and call the builders once per homogeneous group (function barrier). POM-only, no IOM change.

2. core/problem_template.jl (_add_contributing_device_by_type!) — the contributing_devices_map value is Vector{<:IS.InfrastructureSystemsComponent} (abstract element), so the push! dynamic-dispatches. Rooted in the IOM ServiceModel.contributing_devices_map field type.

3. core/problem_template.jl (service-model attach) — device_model.services::Vector{ServiceModel} (abstract element), so the push! and later iteration dynamic-dispatch. Rooted in the IOM DeviceModel.services field type.

IOM roots

Sites 2 and 3 — and the analogous get_contributing_devices flattens in IOM service_model.jl — trace to abstract field types on IOM structs (ServiceModel.contributing_devices_map, DeviceModel.services). Fully fixing them needs an IOM struct-typing pass (parameterize the containers on concrete element/axis types), coordinated with IOM #141.

Approach

• Site 1: homogeneous per-device-type groups (function barrier) — can land independently in POM.
• Sites 2/3 + IOM twins: parameterize the IOM struct fields, then adopt in POM.

All build-time only. Deferred from #206.