Bump panlib's Radiance pin to main (rtrad is a year behind)

[adulbrich]

Part of the WebAssembly port epic (#227). Blocks nothing. Maintenance, deliberately deferred.

The situation

radiantlab/Radiance is now on upstream main (2026-07-27), but radiantlab/panlib still pins the Radiance submodule at daf9401f (2025-07-11), 202 commits behind. hdrgen's rtrad is therefore still a year old.

That is intentional. The pin was held so that repointing panlib at the fork could be verified as a strict no-op, independently of a version bump. Now that both have landed, the bump is a separate change with its own validation.

The prerequisite, found by the sync checklist

panlib/cmake/rtrad.cmake keeps a hand-written copy of Radiance's src/common source list. Radiance's own src/common/CMakeLists.txt updates on an upstream sync; panlib's does not. Running the checklist from FORK.md:

Radiance rtrad @main: 102   @pin(daf9401f): 101   panlib rtrad.cmake: 109

Radiance's own rtrad list, pin -> main:
  added:   readCSV.c
  removed: none

In Radiance@main but MISSING from panlib:
  readCSV.c

readCSV.c must be added to cmake/rtrad.cmake in the same commit that bumps the pin — not before. The file does not exist at daf9401f, so adding it now breaks the build.

Two things already checked, so nobody re-derives them:

• random.c also appeared in src/common since the pin, but it is not in Radiance's own rtrad_SOURCES at main, so panlib does not need it. readCSV.c is the only addition required.
• The 8 entries panlib has that Radiance's list lacks are not drift. They are the platform-conditional sources panlib adds itself (unix_process.c, win_process.c, win_popen.c, win_usleep.c, strlcpy.c, strnstr.c) plus the two cpprad C++ sources (abitmap.cpp, abitmapio.cpp).

Steps

1. In radiantlab/panlib, on one commit: add readCSV.c to cmake/rtrad.cmake and bump external/radiance from daf9401f to Radiance main.
2. Bump radiantlab/hdrgen's external/panlib submodule.
3. Rebuild hdrgen (native and wasm) and confirm output is unchanged on both reference brackets. This is the actual work, and the reason this is not a one-line change: rtrad is linked into hdrgen, so a Radiance bump can move hdrgen's numbers.

Native hdrgen is bit-reproducible run to run (established in #228), which is what makes step 3 a meaningful check rather than a vibe.

Why bother

Two reasons, neither urgent:

• Consistency. The Radiance tools now run at main while hdrgen's rtrad runs at a commit from a year earlier. They share a codebase; having them disagree about which version of src/common they contain is the kind of thing that produces a confusing bug report later.
• It gets harder the longer it waits. 202 commits is already enough that the bump surfaced two Emscripten problems in the tools (see Phase 1: compile the seven Radiance C tools to WebAssembly #229). The next bump inherits everything skipped.

Watch for

Upstream added add_compile_options(-mavx2 -mfma) globally for non-Apple UNIX builds during this window, which is what broke the Emscripten build of the Radiance tools. panlib forces its own flags into the libjpeg-turbo ExternalProject, so check whether anything similar reaches that sub-build.