Add ProgramIdMappings entity + UsagePoint↔ProgramIdMappings relationship (energy)

[dfcoffin]

Gap (found by the #119 atom:link-vs-entity/DDL audit)

The NAESB 4.0 UML model defines UsagePoint <-> ProgramIdMappings as an atom:link rel="related" association (<<link>> stereotype), but there is no ProgramIdMappingsEntity in openespi-common (and therefore no UsagePoint↔ProgramIdMappings JPA relationship). All other UsagePoint related resources (MeterReading, ElectricPowerQualitySummary, UsageSummary, LocalTimeParameters/TimeConfiguration) have entities + navigable relationships.

Impact

The canonical resource surface (#119) cannot emit the UsagePoint → ProgramIdMappings related link (nor serve a ProgramIdMappings resource) until the entity + relationship exist. Until then, E2 (UsagePoint) emits its other 4 related links and omits ProgramIdMappings.

Work

• Add ProgramIdMappingsEntity (extends IdentifiedObject) + ProgramIdMapping element per espi.xsd, DTO, mapper, repository, Flyway DDL (the program_id_mappings table may need adding/verifying across MySQL/PostgreSQL/H2).
• Add the UsagePoint↔ProgramIdMappings JPA relationship (FK) matching the UML multiplicity (UsagePoint [1..*] <-> ProgramIdMappings [0..1]).
• Then wire the ProgramIdMappings related link + resource into the Remediation: ESPI REST controller modernization (post-#116) #119 surface.

Related: #119 (resource surface), #101/#123 (entity/DDL ↔ XSD compliance).