r506w kill the r505/r506 post-DEVICE grind: bounded op-failure latch + exact release routing

Two independent defects turned one unresolvable virtual op into a
client-wide hang (r505 multikernel, r506 matmul: 'client at DEVICE
forever' while the pump ground its stream at ~10 s per push):

- an op that keeps failing -ENOENT re-runs on every decode pass and
  re-set svc.op_tr_pending each time, so its push held for the full
  SVC_OPDEF_HOLD_MS opdef bound every pass (r506 witness: the RM's
  channel-progress zeroing at 0x2000c0xxx, 1913 failed attempts, 65 ring
  entries in ~90 s). New per-VA failure latch: after 8 failures the op
  still attempts its write but stops forcing the hold; the entry consumes
  and its withheld release applies - exactly the outcome the expired
  bound already sanctioned, minus the 10 s tax.

- svc_rel_apply_launch routed EVERY release through the exact-slot
  counter fallback (release_pa ?: counter_pa), which writes (and
  forward-only-skips against) the channel's registered completion slot -
  a different word. The tracker releases to 0x20480fef0 were skipped
  against the polluted PUT counter (cur=96) and lost: rel-apply
  h=0x5c000059 pa=0x10809def0 pay=1 cur=96 -> skip. The fallback is now
  restricted to counter VAs; generic releases are forward-only by value
  (payload > fresh cur) so a decode blinded by a stale landing can no
  longer drop them.

0 files changed, 0 insertions, 0 deletions