[ext-fintraffic] Persist and expose parking lighting

[teppope]

Note: This implementation would benefit from a proper multi-module Maven structure that separates the Fintraffic extension from the core module. Without module isolation, FintrafficParking is always on the Hibernate classpath even in core test contexts, requiring the extension to use separate collection tables (rather than simpler scalar columns) to avoid selecting non-existent columns in core tests. See the related proposal: #416 – refactor: introduce multi-module Maven structure (Phase 1).

Note: This change is proposed as a Fintraffic extension rather than a core change because SiteElement.lighting is @Transient in the core JPA model — there is no existing persistence for Parking.lighting. If adding a lighting column to the core parking table is acceptable, the implementation can be easily moved to src/main/ (add @Column directly on a Parking subclass or override in Parking, add a core Flyway migration, and wire in ParkingUpdater / CustomGraphQLTypes — no structural changes needed).

Note: This PR depends on the vehicle entrances ext PR (feat/ext-fintraffic-vehicle-entrances) being merged first.

Summary

• Exposes lighting as a readable and mutable field on the parking GraphQL types when the fintraffic Spring profile is active.
• Adds a persistent parking_fintraffic_lighting collection table via ext Flyway migration V6.
• Handles lighting in FintrafficParkingUpdater: written on mutation, preserved on version update when not included in input.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update (changes to documentation only)
• Other (please describe)

Issue

SiteElement.lighting is annotated @Transient in the core model, so Parking.lighting is never written to or read from the database. This PR addresses the gap for the Fintraffic deployment by:

• Subclassing Parking as FintrafficParking (already in place) and adding a lightingList field mapped via @ElementCollection to a separate parking_fintraffic_lighting collection table (same pattern as paymentMethods, infoLinks, vehicleEntrances). Using a separate table prevents Hibernate from selecting an ext column in core tests that do not run the Fintraffic Flyway migrations.
• Running a Flyway Java migration (V6__FintrafficParkingLighting) to create the parking_fintraffic_lighting table.
• Wiring lighting into FintrafficParkingGraphQLTypeContributor (output + input) using the existing CustomGraphQLTypes.lightingEnumType.
• Reading and writing the field in FintrafficParkingUpdater.populateExtendedFields / preserveExtendedFields.

The LightingEnumeration Java enum and lightingEnumType GraphQL enum type already exist in core and are reused unchanged.

Unit tests

Three integration tests added to FintrafficGraphQLParkingIntegrationTest:

• mutateParking_lighting_persistedAndReturnedInResponse — mutates parking with lighting: wellLit, asserts mutation response and DB entity.
• mutateParking_lighting_persistedAndReadBack_viaQuery — separate parking(id: …) query after mutation proves the value survives a round-trip, not just an echo.
• mutateParking_updateWithoutLighting_preservesExistingLighting — update mutation without lighting field leaves the previously stored value intact.

All tests pass.

Documentation

FintrafficParking Javadoc updated to describe the separate-table pattern and its rationale.