fix: restore PostGIS via boost-serialization from EPEL 10

[fatherlinux]

Summary

• boost-serialization-1.83.0-5.el10 is now available in EPEL 10, satisfying the missing libboost_serialization.so.1.83.0 dep that broke postgis35_17 since 2026-04-09
• Removes the silent || fallback in the Containerfile that allowed builds to succeed without PostGIS — causing Serper geographic grounding to silently degrade to ungrounded searches for every POI
• Adds integration tests for PostGIS presence, boundary_geom column existence, and the actual grounding SQL so this class of silent failure is caught by CI going forward

Test plan

• CI build succeeds with postgis35_17 installed (no fallback needed)
• PostGIS extension is installed integration test passes
• pois table has boundary_geom column integration test passes
• Serper grounding query executes without error integration test passes
• All other existing tests continue to pass

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the Containerfile to explicitly install boost-serialization as a dependency for PostGIS on RHEL 10 and adds integration tests to verify PostGIS installation and geographic grounding logic. Review feedback suggests optimizing the Containerfile by combining dnf install commands and identifies several issues in the new integration tests, including a geometry type mismatch in the test data insertion, missing geom column population for point POIs, and the need for more robust assertions to validate spatial query results.

[gemini-code-assist]

Combine these dnf install commands into a single execution. This reduces the number of image layers and minimizes metadata overhead, leading to a more efficient build process.

    dnf install -y boost-serialization \
        postgresql17-server postgresql17 postgis35_17 && \

[gemini-code-assist]

The boundary_geom column is defined as a MultiPolygon (per migration 022). Since ST_MakeEnvelope returns a Polygon, this insertion will fail due to a type mismatch. Wrap the envelope in ST_Multi() to ensure it matches the column's geometry type.

Suggested change

	INSERT INTO pois (name, poi_type, latitude, longitude, boundary_geom)
	VALUES (
	'_test_boundary', 'boundary', 41.3, -81.6,
	ST_MakeEnvelope(-82.0, 41.0, -81.0, 41.6, 4326)
	)
	INSERT INTO pois (name, poi_type, latitude, longitude, boundary_geom)
	VALUES (
	'_test_boundary', 'boundary', 41.3, -81.6,
	ST_Multi(ST_MakeEnvelope(-82.0, 41.0, -81.0, 41.6, 4326))
	)

[gemini-code-assist]

The grounding query being tested (lines 196-217) retrieves the location for point POIs from the geom column. However, this test insert only populates latitude and longitude. In this test environment, the geom column won't be automatically updated, causing the query to find a NULL geometry and return no results. Populate the geom column explicitly to correctly test the spatial join logic.

Suggested change

	const testPoi = await pool.query(`
	INSERT INTO pois (name, poi_type, latitude, longitude)
	VALUES ('_test_point', 'point', 41.2, -81.5)
	RETURNING id
	`);
	const testPoi = await pool.query(`
	INSERT INTO pois (name, poi_type, latitude, longitude, geom)
	VALUES ('_test_point', 'point', 41.2, -81.5, ST_SetSRID(ST_MakePoint(-81.5, 41.2), 4326))
	RETURNING id
	`);

[gemini-code-assist]

The assertion expect(Array.isArray(result.rows)).toBe(true) is insufficient as it passes even if the query returns an empty array (meaning grounding failed). To properly validate the PostGIS functionality, verify that the query returns exactly one row containing the expected boundary name.

      expect(result.rows.length).toBe(1);
      expect(result.rows[0].name).toBe('_test_boundary');