fix: fall back to WKT for WMTS BoundingBox crs when CRS cannot be resolved to a URN

[wakame1367]

closes #1043

What

When the wmtsExtension is configured with a custom CRS that cannot be
resolved to an authority identifier (e.g. a slightly tweaked polar
stereographic projection), CRS_to_urn() returns None and the WMTS
Capabilities document ends up with an invalid bounding box CRS:

<ows:BoundingBox crs="None">

This breaks WMTS clients such as QGIS.

This PR implements the fallback discussed in #1043: when no URN can be
resolved, we now emit a UserWarning and use the WKT representation of the CRS
for the crs attribute. WKT is not strictly compliant with the WMTS 1.0.0
expectation that this value be a CRS URI/URN, but GDAL/QGIS handle it
correctly, and it is preferable to emitting crs="None".

The same fix is applied to both titiler.extensions.wmtsExtension and
titiler.mosaic.extensions.wmtsExtension, and the now-unneeded
# type: ignore comments are removed.

Changes

• titiler/extensions/wmts.py / titiler/mosaic/extensions/wmts.py: fall back
  to geographic_crs.to_wkt() (with a UserWarning) when
  CRS_to_urn(geographic_crs) returns None
• add tests for both extensions using a custom CRS that cannot be resolved to
  an authority, asserting that a UserWarning is emitted and that the crs
  attribute of ows:BoundingBox contains the WKT string
• update CHANGES.md

🤖 Generated with Claude Code

[wakame1367]

The remaining red on this PR's tests jobs is not caused by this change.
The mypy step fails on two pre-existing [call-overload] errors in
titiler/core/algorithm/dem.py (lines 182 and 242) that are already failing on
main — see e.g. the CI run for the latest merge commit on main, which fails
with the same two errors.

I opened #1449 to fix that pre-existing mypy failure separately. Once it lands
(and this branch is rebased on top), this PR's CI should be green.