Verify and source Java/PostgreSQL support ranges for the component-versions tables

[miharp]

Summary

The component-versions page has two hand-maintained "supported requirement" columns
that aren't sourced from any authoritative data: Java and PostgreSQL (for
the server and OpenVoxDB tables). These are typed directly into the page template and
can drift from reality. We should both (a) verify the current values and (b) consider
sourcing them from a structured upstream file the way the supported-platforms page now
consumes platforms.json.

Spun out of a review comment on #377 (component-versions server/OpenVoxDB SBOM
migration).

Thread 1 — verify the supported PostgreSQL range

The OpenVoxDB table currently shows PostgreSQL 11+ (14+ recommended), matching
the existing prose in docs/_openvoxdb_8x/index.md and
docs/_openvoxdb_8x/puppetdb-faq.markdown. But per @bastelfreak, we don't actually
know the oldest working version — OpenVoxDB CI only tests PostgreSQL 16–18
(openvoxdb 8.x main.yml),
"the rest is ancient."

So there's a gap between the documented minimum (11) and the tested range (16–18).
We should decide what the supported-version statement should actually say, and update
all three places consistently (the table cell plus the two OpenVoxDB pages) so they
don't conflict.

Note the Java column has the same hand-maintained nature: server shows 17, 21,
OpenVoxDB shows 11, 17 (the latter matching its docs). These are also typed by hand.

Thread 2 — source the ranges from a structured file

@bastelfreak suggested refactoring the version list into a JSON file in
OpenVoxProject/shared-actions. This parallels what the new Supported platforms
page (#303) already does: it generates from shared-actions/platforms.json. A
companion file (e.g. versions.json carrying supported Java / PostgreSQL ranges per
series) could feed the hand-maintained Java and PostgreSQL columns the same way,
removing the drift risk entirely.

Implementation would mirror the existing generated-table plumbing
(lib/puppet_references/): fetch the file, write a _data/*.yml, render via Liquid.

Scope / acceptance

• Decide the authoritative PostgreSQL support statement (documented min vs. tested
  range) and update the table + index.md + puppetdb-faq.markdown consistently.
• (Optional, larger) Add a structured version-ranges source in shared-actions and
  generate the Java/PostgreSQL columns from it instead of hand-maintaining them.

Related

• Source the server and OpenVoxDB component tables from SBOMs #377 — the PR this was raised on.
• [Feature request]: Document supported platforms based on authoritative source #303 — supported-platforms page, the existing shared-actions/platforms.json consumer.
• Generate Component Versions tables from openvox-sbom-tools #363 — the component-versions SBOM migration these columns live alongside.