gdalcubes archived on CRAN breaks the pkgdown deploy and user installs

[NewGraphEnvironment]

Problem

The pkgdown workflow has failed on every push since 2026-09-26 (runs 36257119060 on a7b7537, 36257649915 on 7dca4a6). The last successful deploy was 7011fa6 on 2026-09-07, so the published site is stale.

It fails in setup-r-dependencies, before the package is built:

Could not solve package dependencies:
* deps::.: Can't install dependency gdalcubes
* gdalcubes: Can't find package called gdalcubes.

Cause: gdalcubes was removed from CRAN. It was archived on 2026-09-16 because "issues were not corrected in time" (https://cran.r-project.org/web/packages/gdalcubes/index.html). drift lists it in Suggests, and the workflow installs local::. with needs: website, so pak tries to resolve it and gives up.

This goes beyond CI. dft_stac_fetch(), dft_stac_cube() and dft_index_expr() call gdalcubes::, so a new user can no longer get the core fetch step from CRAN.

Upstream state (checked 2026-09-28)

• appelmar/gdalcubes is active and not archived. It was last pushed 2026-09-15 and main is at 0.7.5.
• The latest tag is v0.7.4. inst/notes/gdalcubes-pc-gotchas.md documents 0.7.3.
• SystemRequirements: GDAL, PROJ, netcdf, sqlite3. A source install on the runner needs these; pak's sysreqs should cover them on ubuntu.
• The upstream tracker has no issue about the archival yet. Per the conventions, do not post there without approval.

Resolution (PR #84, 2026-09-28)

Option 1 was taken, with no suffix: appelmar/gdalcubes in Remotes:, following the pin policy (no suffix by default, never a bare SHA). Upstream master (0.7.5) had already merged our filter_geom fix (their PR #111), so the fork is no longer needed; the gotchas note says so.

Two more things landed with it:

• The three gdalcubes guards now give the GitHub install in their error. rlang::check_installed() would have offered a CRAN install that fails.
• Verifying 0.7.5 surfaced five opt-in network assertions on the pre-Cache key moved on an rlang upgrade, silently orphaning every cached cube and fetch #48 cache path, and those were fixed.

The PR's pkgdown run built gdalcubes from source on the runner and passed.

Options (as filed)

1. Add appelmar/gdalcubes to Remotes: (recommended). This fixes CI and user installs together. It pins a GitHub remote, so decide between a tag pin (@v0.7.4) and no suffix. Check that the gotchas in inst/notes/gdalcubes-pc-gotchas.md (filter_geom segfault, reduce_time closures) still behave the same on the version installed.
2. Keep gdalcubes out of the pkgdown install only. For example, dependencies: '"hard"' plus the vignette Suggests listed explicitly. This turns the site green, but users still can't install from CRAN. The vignettes don't reference gdalcubes, so the site would build.
3. Wait for a CRAN re-release. This leaves the site stale for an unknown time.

Done when

• The pkgdown workflow is green on main, and the gh-pages deploy commit matches HEAD.
• The README install instructions are correct for users who don't have gdalcubes.