HRX: pin hrx-system to the held-pin backport carrying #409, #410 and #401

config/hrx-long-prompt-validated-pin.config

@@ -12,4 +12,4 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
-98d05d94a9f9e405683f8aeafc037f5ace0abe4a
+3319e536196b99119f30f78b60f39a340aee6a5d

config/hrx-system-hold.config

@@ -22,5 +22,20 @@
 # Held 2026-10-10 by the owner: the engine stays on our HRX line. AMD's hrx-system after
 # 98d05d94 carries the long-context attention miscompile from ba07714dd (ROCm/hrx-system#1535),
 # and the move also needs the loom-jit.cpp port (llama.cpp fork #97) and the kernel corpus
-# rename to `multiple_of`.
-98d05d94a9f9e405683f8aeafc037f5ace0abe4a
+# rename to `multiple_of`. Two of those three reasons were measured on 2026-10-15/16: the
+# loom-jit.cpp LoomC port landed in llama.cpp `ad18320a` (and the merged `hrx-pins-guard`
+# workflow now checks it), and the corpus rename is only needed for AMD's renamed revision -
+# `1bit-MONSTER/hrx-system` `1bit/main` still accepts `mul`, and so does 98d05d94. The #1535
+# long-context question is the one that remains open, which is why this file still names a
+# commit rather than being emptied.
+#
+# 2026-10-16, R1 backport (owner decision): the hold now names `1bit/held-98d05d94-3fixes`,
+# a branch off the held pin carrying three verified fixes - engine#409 (libhrx bounds-checks a
+# length-less ELF extent instead of skipping the check), engine#410 (libhip_intercept covers
+# every HIP symbol the backend exports; env-var and double-init defects fixed) and engine#401
+# (libhsa no longer opens /dev/accel in GPU-only processes) - plus the +61/-0 `api.h`
+# forward-port the regenerated stubs need. The held AMD core is unchanged, so the #1535
+# question stays exactly where it was. The durable move is still to rebase these fixes onto
+# our line (or lift the hold) once the long-prompt check passes there; this line exists so
+# three small fixes do not have to wait for that.
+3319e536196b99119f30f78b60f39a340aee6a5d

docs/hrx.md

@@ -71,6 +71,15 @@ HRX0:    AMD Radeon 8060S Graphics (Node 1) (gfx1151)
   summary and succeeds. Since 2026-10-10 hrx-system is held at `98d05d94`: the engine stays on
   our HRX line while AMD's newer hrx-system miscompiles long-context attention
   ([ROCm/hrx-system#1535](https://github.com/ROCm/hrx-system/issues/1535)).
+- **The backport line (2026-10-16).** The hold now names `1bit/held-98d05d94-3fixes`, a branch off
+  that same held commit carrying three fixes that have nothing to do with the AMD-core move:
+  engine#409 (libhrx bounds-checks a length-less ELF extent instead of skipping the check),
+  engine#410 (`libhip_intercept` covers every HIP symbol the backend exports; the documented
+  interceptor variable works and init is idempotent) and engine#401 (libhsa no longer opens
+  `/dev/accel` in GPU-only processes), plus the +61/−0 `api.h` forward-port the regenerated
+  passthrough stubs need. Nothing under the held AMD core changes, so the #1535 question is
+  untouched. When those fixes are rebased onto `1bit/main` — or the hold is lifted — this line
+  is dropped; until then it is what lets three small fixes ship without a 1688-commit core jump.
 - **The token it needs.** The secret `HRX_BUMP_TOKEN` is a fine-grained token with
   Contents read/write on `1bit-MONSTER/llama.cpp` and `1bit-MONSTER/engine`, and
   Pull requests read/write on `1bit-MONSTER/engine`.