fix: restore SQL template routing and PostgreSQL coverage

[grabdoc]

This fixes the failing integration build and keeps the PostgreSQL regression coverage for #916 in the same branch.

The SQL template controller now has an explicit GET route for templates that do not use extra path variables. Previously those requests fell through to the generic primary-key route, so 40 template tests returned 400 instead of reaching the template executor. Templates with custom path variables still use the existing wildcard route.

Because the repaired route makes the requested template name reach the file loader, template names are now validated before any filesystem access. They are limited to safe filename characters, path separators and parent-directory references are rejected, and the normalized file must remain inside the configured template directory. Symlinks are not followed. The validation has 12 regression cases covering null, blank, traversal, absolute, nested, whitespace, and encoded-separator input.

The SQLite invalid-update test now uses the supported filter-based PATCH endpoint and sends an unknown column. It verifies the 400 response, the data-access error category, and the exact missing-column detail. The old test called an unsupported PATCH-by-primary-key URL and therefore received 405 before validating the payload.

The PostgreSQL fixture creates stg."FilmData" and stg."überall" in a real container. Its endpoint tests cover exact-case lookup both without a profile header and with Accept-Profile: stg. The Unicode test also proves that the table name survives URL encoding, Spring path decoding, metadata lookup, and quoted SQL execution. Together they confirm the identifier fix from #948 through the full request path.

Validation completed locally:

• 63 affected integration tests passed across DB2, MariaDB, MySQL, Oracle, PostgreSQL, and SQLite.
• All 13 PostgreSQL SQL-template integration tests passed after the filename validation was added.
• All 12 unsafe-template-name regression cases passed.
• Both PostgreSQL case-sensitive table journeys and the Unicode table-name journey passed.
• The SQLite negative update returned the expected typed 400 response.

Related to #916 and #961.

[grabdoc]

The two new PostgreSQL tests passed in CI. Both requests reached stg."FilmData" and returned the expected row, including the request with Accept-Profile: stg.

The overall Maven job is still red because it reaches the existing 41 integration-suite failures: 40 SQL-template route failures and the SQLite PATCH route mismatch. Those failures are already tracked in #961 and none came from PgCaseSensitiveTableNameTest.

CodeQL and both analysis jobs passed. This PR is ready for an independent review.

[thadguidry]

@grabdoc We should also have a unicode character or two in a table name as well, for the tests. Please add that, say like:

überall

which is German for "everywhere".

This will ensure unicode chars can be used in table names and objects without a problem.

[grabdoc]

Thanks, Thad — I added stg."überall" to the PostgreSQL container fixture and an end-to-end test that reads it through /v1/rdbms/pgsqldb/überall with Accept-Profile: stg. This covers the URL encoding and decoding path as well as metadata lookup and the generated quoted SQL. The focused test passes locally, and the full Maven build is green on commit 828ad74b. Could you take another look when you have a chance?

[thadguidry]

Hmm but I think it might fail if escaped unicode characters are used?

U&"d\0061t\+000061"

And is UESCAPE usage allowed?

See docs https://www.postgresql.org/docs/current/sql-syntax-lexical.html

[thadguidry]

Maybe UESCAPE clause itself needs to be a parameter?

&uescape="!"&filter=