fix: probe actual GIS capability instead of inferring it from the DB platform

[torvalstrom]

Problem

SimplePlaceResolver::detectGisType() infers GIS capability from the DB platform name: any PostgreSQL platform is assumed to have PostGIS. On a plain postgres server (no PostGIS extension - the common case for Nextcloud installs) every queryPoint() call then runs spatial SQL that can only fail:

• one error_log line per photo per cron run - on a ~30k-photo library that was ~8,600 log lines/day, and ~47k/day on a 64k-photo library
• one doomed query per point before the code falls back anyway

Fix

Probe the actual capability once, in the constructor path:

• postgres: SELECT 1 FROM pg_extension WHERE extname = 'postgis'
• mysql/mariadb: try a trivial ST_Contains() (built-in since MySQL 5.7 / MariaDB 10.2, but a stripped build also degrades cleanly this way)

If the probe fails, detectGisType() returns GIS_TYPE_NONE, so queryPoint() goes straight to fallbackByFileId() - which resolves places from the oc_memories_places table that Memories precomputes at index time. Place names still resolve fully; all three callers already pass fileid.

Verified

Running this exact change in production on Nextcloud 33 + plain postgres 16 since July: occ journeys:cluster over 64,341 photos → 1,105 clusters, 0 resolver errors (previously tens of thousands per day). Behavior on a server that does have PostGIS is unchanged (probe returns true, spatial path used as before).

🤖 Generated with Claude Code

[torvalstrom]

Superseded by #36, which fixes the underlying cause rather than detecting it.

The probe in this PR was the right call given what I knew at the time, but it treats PostGIS as the missing ingredient. It isn't: Memories stores memories_planet_geometry.geometry as PostgreSQL's built-in polygon type and queries it with built-in operators, so the PostGIS path was never going to work on a stock install. This PR therefore stops the log flood by turning the spatial lookup off for every PostgreSQL user, leaving results to the per-file fallback only.

#36 uses the built-in operators instead — no extension needed, and indexable against the GiST poly_ops index Memories already creates (1.7 ms vs a 437 ms sequential scan). It carries the hasMysqlGis() probe from this PR forward, so nothing here is lost.

Closing in favour of #36. Thanks for your patience with the two rounds.