RS_FromPath: optional `format` argument + infer format from the URI

`RS_FromPath(path)` always opens the file through GDAL and leaves the band's `outdb_format` null. That's fine while GDAL is the only byte-loader backend — null routes to the GDAL catch-all — but it means there's no way to point `RS_FromPath` at a non-GDAL backend, and the band it produces isn't self-describing.

Two tweaks:

- Accept an optional second argument, `RS_FromPath(path, format)`, that sets `outdb_format` directly so a caller can target a specific backend.
- When it's omitted, infer the format from the URI extension (`.tif`/`.tiff` → geotiff, `.zarr` → zarr, …) and stamp it on the band, falling back to the current GDAL behavior when the extension is unknown.

The loader registry already dispatches on `outdb_format`, so this is entirely producer-side — no changes to the loader machinery.

A couple of things to settle when we pick this up:

- For the GDAL path the dataset is already open, so we can stamp the authoritative driver (`dataset.driver().short_name()`) instead of guessing from the extension. We should decide whether the stored value is a normalized label (`geotiff`) or the raw driver name (`GTiff`).
- Producing an actual non-GDAL (e.g. Zarr) band is more than a format tag — Zarr bands are chunk-anchored, which today is `sd_read_zarr`'s job — so the non-GDAL path may need to delegate to that machinery rather than just labeling the band.

Start by locating RS_FromPath and the loader registry that dispatches on outdb_format. Read sd_read_zarr to understand the chunk-anchored non-GDAL path, and inspect how dataset.driver().short_name() is exposed. Done means the optional format is supported, known URI extensions are inferred, unknown extensions retain GDAL behavior, and the stored driver label is consistent.

Written by the indexing model from the issue text.