Fix four defects in the table-create and query paths

[jh-RLI]

Summary of the discussion

Four defects where the API accepted a request, did something other than what was
asked, and reported success — plus one test-only change that defends a contract
nobody had asserted. Found while answering a user support question about
bounding-box queries; one of them is the standing report in
[openego/ding0#405](openego/ding0#405).

What was wrong

1. A field alias was parsed and discarded. {"type": "column", "column": "name", "as": "who"} in an advanced search came back named name; a
   labelled function came back as upper_1. col.label(...) was called without
   binding the result. Any client keying results by column name broke silently.
2. Unsupported constraint types were dropped without a word. The create path
   branched on PRIMARY KEY and UNIQUE and fell off the end of the chain for
   everything else, so a FOREIGN KEY or CHECK in the payload vanished and
   the request returned 201.
3. Two paths swallowed the database's reason. A failed create answered
   Could not create table <name>; a failed spatial query answered Invalid request. In the ding0 case PostGIS had said exactly what was wrong — could not parse proj string '4326' — and the API dropped it. That is why the
   report stayed open: the message gave nobody anything to act on.
4. The geometry type modifier was parsed by accident. geometry(Point,4326)
   put the whole modifier into GeoAlchemy2's geometry_type and never set
   srid, rendering geometry(POINT,4326,-1). Postgres reads the first two
   values and ignores the third, so the declared SRID landed correctly — by
   accident. Nothing asserted either that or the automatic GiST index, which
   comes from a library default rather than from our code.

What changed

• The labelled expression is bound. An invalid alias now fails with the existing
  identifier error instead of falling back to a generated name.
• The create path rejects constraint types it cannot apply, naming the supported
  route: foreign keys after creation through the table endpoint (which the alter
  path already implements), check constraints unsupported (which that same alter
  path already answers). Rejection happens while parsing, before any Main Table
  exists, so the existing all-or-nothing behaviour covers cleanup.
• Both failure paths consult one policy, reflectable_cause in api.error,
  which answers whether a database cause may be disclosed. The query path's
  inline pgcode allowlist and its single hard-coded PostGIS message move there
  unchanged; the projection-parse message is added. PostGIS raises everything
  under the generic internal-error code XX000, which also covers real server
  faults, so recognition has to be by message text — deliberately narrow, not
  "all internal errors". Causes outside the policy still report the generic
  message, and the full exception still goes to the log either way.
• The geometry modifier is split into subtype and SRID. A non-numeric SRID is
  rejected with a named error instead of reaching postgres as part of the type.

Testing

19 new tests across four regression modules, all driven through the HTTP
endpoints via the existing APITestCase.api_req helper — no new test seam, and
no assertions on generated DDL. Every test was verified red before green.

Notable: four of the five geometry tests pass on the unfixed parser. That is the
finding — the contract was undefended, not broken. Their value is that a
dependency upgrade changing GeoAlchemy2's spatial_index default now fails a
test instead of silently stopping the indexing of every new geo table.

The geometry tests need PostGIS and will fail against a plain postgres; there is
a note to that effect in the module.

Full suite: 404 tests, one pre-existing environment failure (the oekg SPARQL
test needs the fuseki hostname from the container network).

Deliberately not in this PR

• Foreign key support at creation time. It needs decisions this PR has no basis
  to make — cross-topic references, what permission the referenced table
  requires (the alter path currently checks none, with a FIXME on that line),
  and what a foreign key means for rows sitting in a Journal Table before Apply.
• Check constraint support, at creation or afterwards.
• Indexes on non-geometry columns. Still a maintainer action on request.
• Type checking the Advanced Query API's function arguments. The API forwards
  calls without knowing their signatures; coercing numeric-looking strings is
  rejected outright, since it would change the meaning of requests that pass
  numeric strings on purpose.

Workflow checklist

Automation

Closes #

PR-Assignee

• 🐙 Follow the workflow in
  CONTRIBUTING.md
• 📝 Update the
  CHANGELOG.md
• 📙 Update the documentation on
  mkdocs

Reviewer

• 🐙 Follow the
  Reviewer Guidelines
• 🐙 Provided feedback and show sufficient appreciation for the work done