Update web and db images for upstream compatibility

[Rub21]

• Ruby 3.3 → 3.4 (builder + runtime).
• Bundler pinned to 2.6.9
• Bundler reinstalled in runtime stage to avoid Passenger Gem::LoadError.
• Base image postgres:17 → postgis/postgis:17-3.5 (PostGIS now required by upstream for area filtering on comments).

@erictheise quick question — is the upstream merge branch ready to test on staging?

I tested it locally but the map is broken. Let me know when it's ready so we can deploy it on staging. I also need to check the database carefully, since we are switching to a Postgres 17 image that already includes PostGIS.

[erictheise]

@Rub21, upstream uses Bundler 4.0.10 as do I, locally, so I do not understand the need to pin 2.6.9 (it's from May 13, 2025, which is not as bad as I expected, but 4.0.12 is current). We should be using the same major version, v4.

The map is not broken for me, locally, since late yesterday afternoon (probably with b4a38ffdb7cb0ee70e29029dbf71601c7694051d). Locally I have four or five test failures, all but two of which are due to the addition of two new translations from upstream that use {fastly} and those will be easy to fix; I just haven't done it yet. Running Github actions on the branch produces more errors but those appear to be the same Capybara errors that plague us in our current version.

As to pushing to staging: I am presently debugging an issue where the "minimaps" shown in the right panel layer picker don't work for vector layers, ours or theirs. My branch currently brings in OSM's iD via npm, not ours. Vendoring is over. Upstream iD reorganized some translation keys and I'll need to do another catchup with our iD to pick those up. Shouldn't be difficult; we're not far behind at this stage.

Sorry for the long winded answer.

If the point of putting it on staging is to test your deployment environment, go ahead. If it's to do a pre-release functionality test, it's not ready today. Should be ready tomorrow or over the weekend.

[erictheise]

{fastly} and other translation-related issues were resolved in OpenHistoricalMap/ohm-website@cdfeba8.

[Rub21]

I have deployed this branch in staging using the latest Git SHA ecd8301fd333946b50137fb702bb5c1cbd1c3970
https://github.com/OpenHistoricalMap/ohm-website/commits/upstream-merge/, And added a postgis extesion for the database,

I have also tested the ModerationZone, and it works. I manually created a ModerationZone using the following snippet:

ModerationZone.create!(
  name: "ayacucho-test",
  reason: "test postgis enforcement en zona Ayacucho",
  creator: me,
  zone: "POLYGON((-74.30 -13.25, -74.14 -13.25, -74.14 -13.08, -74.30 -13.08, -74.30 -13.25))"
)

• Inside the zone: It triggers a 403 error as expected.

• Outside the ModerationZone: It works perfectly, and we can successfully create an anonymous note there.

cc. @1ec5