Add an eca_geofield_pgrouting submodule for network analysis and routing workflows

Problem/Motivation

ECA Geofield exposes core PostGIS spatial operations as ECA actions and conditions, but it has no support for network analysis. Use cases such as finding the shortest path between two points, calculating routing costs, or determining the area reachable within a given cost currently require custom development. Integrating pgRouting would make these workflows available directly in the ECA UI.

pgRouting is a separate PostgreSQL extension that most sites using this module will not have installed, so it should not become a requirement of the main module.

Steps to reproduce

1. Install ECA Geofield on a PostgreSQL database with PostGIS and pgRouting, and a road network table.
2. Try to build an ECA model that calculates a route between two geofield points.
3. No routing action is available.

Proposed resolution

Add a new submodule, eca_geofield_pgrouting, that depends on eca_geofield and requires the pgrouting PostgreSQL extension. The main module stays unchanged and keeps working without pgRouting.

The first iteration adds one action, "Geofield: calculate shortest path (pgRouting)", based on pgr_dijkstra, with the following configuration:

• Entity (ECA token), start point field, end point field and target field (geofields).
• Edge table, and its id, source, target, cost, reverse cost and geometry column names.
• Vertex table and its geometry column, used to snap the start and end points to the nearest network vertex.
• Whether the graph is directed.

Behaviour:

• Table and column names are never inserted into SQL as given. They are validated against information_schema and quoted as identifiers before the edges SQL passed to pgr_dijkstra is built, so the action cannot be used to run arbitrary SQL.
• The start and end points are snapped to the nearest vertex with a KNN (<->) query.
• The SRID of the network is detected from the edge table's geometry column. Geofield points are transformed into the network SRID before snapping, and the resulting route is transformed back before it is written, with ST_Transform.
• The edges returned by pgr_dijkstra are joined with their geometries in path order and merged into a single LINESTRING, which is written into the target field. The total cost is made available as an ECA token.
• If no path exists, or the pgrouting extension is missing, the target field is left unchanged and a message is logged.
• The submodule's hook_requirements() reports whether the pgrouting extension is installed.

Network tables are expected to exist already; the submodule does not create or manage them. The unit of the cost column (for example metres or seconds) is up to the network and is documented as such.

Follow-ups:

• A catchment area action based on pgr_drivingDistance, in its own child issue. This function returns reachable vertices with their cost, not polygons, so the action also needs a hull step (for example ST_ConcaveHull) to produce an area geometry.
• An optional submodule that builds a routing network from OpenStreetMap data fetched through Overpass API, handled in #3625899. It depends on overpass_api, while eca_geofield_pgrouting itself does not, so networks built with other tools (for example osm2pgrouting or existing road data) keep working without it.

Remaining tasks

• Create the eca_geofield_pgrouting submodule and the shortest path action.
• Write kernel tests against a small fixture network, including identifier validation, SRID transformation and the no-path case.
• Extend the CI configuration from #3625568 so the submodule's tests run on a database image that includes pgRouting.
• Document the submodule, its requirements and the expected network table structure in the README.
• Open the child issue for the catchment area action.

User interface changes

A new action, "Geofield: calculate shortest path (pgRouting)", becomes available in the ECA modeller when the submodule is enabled.

API changes

A new submodule with a new action plugin. No changes to the existing plugins or services of the main module.

Data model changes

None. The routing network tables required by pgRouting are managed outside of the module.