docs(asm): symbol refs are portable — explain the auto-:c mechanism

Updates the symbol-operand guide: x86 now uses the same plain %[fn] as
aarch64, and a 'How the portability works' note explains the mechanism
(compiler auto-injects LLVM's :c modifier for "s" operands, equivalent
to GCC :P/%P0 for x86 calls, no-op on aarch64, overridable). Drops the
stale per-arch :P guidance; checkpoint updated.

current/CHECKPOINT-ASM.md

@@ -372,9 +372,16 @@ Orthogonal: **issue 0137** (no-`main` segfault).
   arches: 1657 read-write (`"incq ${0}","=r,0"`), 1658 indirect (`"movq $$42,
   ${0}","=*m"`(ptr elementtype)), 1659 symbol (`"call ${2:P}"`, direct call). x86
   templates validated by cross-emitting an object (integrated assembler accepts;
-  objdump confirms 1659's direct `call` reloc). **Note:** x86 direct calls need
-  the `P` operand modifier (`%[fn:P]`); aarch64 `bl %[fn]` needs none. Pure
-  additive locks. `zig build test` green (668 corpus, 446 unit).
+  objdump confirms 1659's direct `call` reloc). Pure additive locks. `zig build
+  test` green (668 corpus, 446 unit).
+- (symbol portability) made `%[fn]` portable across arches — `renderAsmTemplate`
+  auto-injects LLVM's `:c` modifier (`${N}`→`${N:c}`) for symbol (`"s"`) operands
+  lacking an explicit modifier (`asmNamedIsSymbol` helper). Without it x86 renders
+  `$cb` (a bad `call` target needing a hand-written `:P`); aarch64 unaffected.
+  Verified `:c` ≡ `:P` for x86-64 calls (both → `R_X86_64_PLT32`). Explicit
+  `%[fn:X]` still wins (escape hatch). 1659 dropped its `:P` → same plain `%[fn]`
+  as aarch64 1656; both IRs regen to `${N:c}`. `zig build test` green (668 corpus,
+  446 unit).
 
 ## Known issues
 - **0138** — RESOLVED. `@const` (address-of a `::` comptime constant) yielded a