[OCPPmulti] Improving configuration synchronization in the OCPPmulti module

### Describe the problem

PR #1571 introduces variable mapping between the OCPP 2.0.1 device model and the EVerest configuration, but it is limited to OCPP 2.0.1. It duplicates or implicitly generates device model component variables, still depends on invoking Auth and EVSE Manager interfaces, and does not fully align with the configuration service as the single source of truth. For OCPPmulti, this leads to divergent values between the OCPP device model and EVerest configuration; At init of OCPP201 the configuration parameters get overwritten. reboot requirements of some config parameters are not surfaced back to the backend; This issue aims to bring OCPPmulti up to date by addressing those shortcomings.

### EVerest Domain

OCPP 2.0.1

### Affected Component

Primary impact: modules/EVSE/OCPPmulti and lib/everest/ocpp_module_common. Secondary updates may be required in libocpp, the configuration service integration, and related unit tests.

### Describe your solution

• Extend the mapping approach from PR #1571 so OCPPmulti uses strict 1:1 mappings (e.g., connection_timeout → TxCtrlr/EVConnectionTimeOut) defined in mapping.yaml, without creating new component variables, and allow each map entry to target either a libocpp or internal EVerest CV. Replace build_everest_config_variables with register_everest_configuration_mappings in lib/everest/ocpp_module_common/src/device_model/everest_device_model_storage.cpp.
• Implement bidirectional runtime sync inside set_variable_attribute_value for ComposedDeviceModelStorage and EverestDeviceModelStorage: SetVariable writes flow through to mapped EVerest configuration parameters, GetVariable reads come from those parameters, and configuration change callbacks update device model storage (without re-triggering the config service).
• Remove redundant Auth and EVSE Manager interface calls (set_connection_timeout, set_master_pass_group_id, PnCEnabled, CentralContractValidationAllowed, ContractCertificateInstallationEnabled) once the configuration service propagates changes.
• Ensure the configuration service can signal “reboot required,” add EVLOG_verbose startup dumps of the device model, reuse the single-source-of-truth mechanisms from PR #2412, fetch GetReport data from persistent storage, and update unit tests to cover the new sync path.

### Alternatives considered

Continuing with dynamic creation of device model variables introduced in PR #1571. Maybe this should be configurable.

### Additional context

The proposal extends PR #1571 (“feat(OCPP201): add variable mapping support between OCPP201 Device Model and EVerest config”) and leverages functionality from PR #2412 (“Use configuration service as single source of truth for module configuration sync”) to centralize configuration truth in the configuration service.