ci: fix the Windows/macOS MaxMin resolution failure that reddened every branch

[ms609]

Fixes #43

The Windows leg of agent-check.yml — and R-CMD-check.yml's windows-latest (release) job —
failed on every branch of this fork, in Set up R dependencies, before compiling anything:

* deps::.: Can't install dependency MaxMin
* MaxMin: Can't find package called MaxMin.

Two mechanisms, and the first fix alone was not enough.

1. The url:: reference — for the lockfile solve

Not a publishing problem, and not a missing field. MaxMin is published, and DESCRIPTION:78
already carries Additional_repositories. But pak does not read that field — which
ms609/packages' tools/publish-maxmin.R had already established from a direct test on
2026-08-03, and is exactly why that script also emits flat, unversioned MaxMin_latest.<ext>
aliases for url:: consumers. The Linux legs name theirs; Windows and macOS named nothing.

Added per platform, using the unversioned alias so it needs no edit when MaxMin moves. All three
URLs verified live, and all three artifacts are Built: R 4.6.1 — the current R release, which
is what these legs request.

2. Pinning install-pandoc — for the second solve

With (1) alone the step got further and still failed, on a different ref:

* local::.: Can't install dependency MaxMin

setup-r-dependencies' "Check whether pandoc needs to be installed" step runs

pak::pkg_deps(".", dependencies = list(direct = "all", indirect = character()))

— a fresh solve that sees neither the lockfile just built nor extra-packages, so it looks
MaxMin up by name and dies, despite MaxMin having installed successfully seconds earlier
(✔ Installed MaxMin 0.0.0.9004 is in the log). That branch only runs when
Sys.which("pandoc") == "". Linux runners ship pandoc and return early; Windows and macOS
runners do not — which is the entire reason this was a non-Linux-only failure, and why the
arm64 leg's url:: line has always been sufficient there.

Pinning install-pandoc skips the auto-detect. Values are per-leg, not uniform: true where
the job checks with vignettes, false for the shinytest2 job, which runs an app and no
vignettes. The quarto auto-detect needs no equivalent — it globs for *.qmd and never calls
pkg_deps.

What is verified, and what is not

Verified failing before, green now — run 30916727681,
ubuntu-arm64 success + windows success, the first fully-green agent-check on this
fork:

• agent-check.yml, windows leg (had no extra-packages block at all)
• R-CMD-check.yml, Set up R dependencies (covr), runner.os == 'Windows' — this was the
  only failing job in run 30910132725

Changed pre-emptively, NOT observed failing. Both were skipped in the diagnosing run, so
they are reasoned-about rather than measured:

• R-CMD-check.yml, EasyTrees shinytest2 — gated on detect app changes
• R-CMD-check.yml, full matrix (macOS-latest arm64, macos-15-intel x86_64) — needs: core, so
  it was skipped because Windows was red. Fixing Windows unskips it, and it would then hit the
  identical error; fixing only Windows would have converted a skipped job into a failing one.
  Note _R_CHECK_FORCE_SUGGESTS_: false does not help there — it governs R CMD check, not
  pak's solve.

R-CMD-check.yml is not dispatched by gha-dispatch.sh, so its Windows and macOS legs are
covered by the same reasoning as the verified agent-check fix rather than by their own green
run. Worth a look when it next runs on a PR.

Unrelated fragility worth knowing

The drat has no bin/windows/contrib/4.7, and MaxMin has no source tarball in src/contrib at
all — it is published binary-only, for R 4.6. So when R 4.7 becomes release, the indexed layout
goes source-only for every package there and MaxMin becomes unavailable by name entirely. The
url:: aliases used here are unaffected in form, but they would then serve 4.6-built binaries
to a 4.7 runner. Not in scope for this PR; flagged so it is not a surprise.

🤖 Generated with Claude Code

[ms609]

The pre-emptive legs are now observed passing, closing the "changed pre-emptively, NOT observed failing" gap in the description above.

Run 30927024203 (on feature/shiny-debounce-wait, which is stacked on this branch, so it carries these commits):

Job	Result
sense-check (ubuntu-24.04-arm, release)	success
windows-latest (release)	success
ubuntu-24.04 (4.1)	success
ubuntu-24.04-arm (devel)	success
macOS-latest (release)	success
macos-15-intel (release)	success
EasyTrees shinytest2 (windows-latest)	failure — #46, fixed in #48

So both macOS legs — arm64 and x86_64, each with its own per-arch url:: line — resolve MaxMin and
check clean. They were skipped in the diagnosing run (needs: core, skipped because Windows was
red), which is why the description could only reason about them. The full matrix has now run.

The only red is the shinytest2 job, which is #46's stale-baseline race, unrelated to dependency
resolution and non-blocking (continue-on-error: true).