refactor(shared): split runResult out of runSubmit (RB-17)

runSubmit did two things at once: fold a call into a Result, and mint
an Idempotency-Key for it. Five call sites are reads and had no
business minting one — brief.adapter.ts:load, org-template.adapter.ts
:list/:load, and stamdata.adapter.ts:list/:load. stamdata.adapter.ts's
own docstring already said "Both endpoints are reads … There is no
write method" while both called runSubmit; that mismatch is the
sharpest evidence, and the reason the baseline's original "~13
mutations" count (derived from the helper's name, not the code) was
wrong by five in one direction.

Split submit.ts in place: runResult is the try/catch + problemDetail
fold with no mint; runSubmit is runResult wrapping
withIdempotencyKey. Zero behaviour change for the 8 real mutations
(brief save/submit/approve/reject/send/reset, org-template
save/publish/rollback) — same fold, same mint, same timing. The five
reads now run the fold with no pendingIdempotencyKey touched.

submit.spec.ts asserts the split behaviourally via
currentIdempotencyKey() (two reads inside the same call agree only
when a key was minted and reused) rather than mocking a relative
import, matching this repo's existing vitest convention. Verified red
without the fix by temporarily reintroducing the mint into runResult.

ApplicationsStore.cancel/AdminCasesStore.delete (RB-20) and
FeatureFlagStore.set are out of scope and untouched — the latter
already calls runSubmit correctly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

libs/shared/src/application/submit.ts

@@ -3,26 +3,36 @@ import { problemDetail } from '@shared/infrastructure/api-error';
 import { withIdempotencyKey } from '@shared/infrastructure/api-client.provider';
 
 /**
- * Run a mutating API call and fold it into a `Result` — the one place the
- * try/catch + ProblemDetails-mapping lives, so every `submit-*` command is just
- * its own payload mapping. The backend re-validates and returns a 422
- * ProblemDetails on rejection, surfaced here as the error string.
+ * Run an API call and fold it into a `Result` — the one place the try/catch +
+ * ProblemDetails-mapping lives, so every adapter method is just its own payload
+ * mapping. The backend re-validates and returns a 422 ProblemDetails on
+ * rejection, surfaced here as the error string.
  *
- * Also the one place a logical submit's Idempotency-Key is minted — once per
- * `runSubmit` call, not per HTTP attempt — so a retry of this same submit
- * dedupes on the backend (see `withIdempotencyKey`).
+ * This is the **read** half: it mints no Idempotency-Key. Use it for GETs.
+ * `runSubmit` below wraps it for mutations — never route a read through that
+ * one, it mints a key for nothing.
  */
-export async function runSubmit<T>(
+export async function runResult<T>(
   fn: () => Promise<T>,
   fallback: string,
 ): Promise<Result<string, T>> {
   try {
-    return ok(await withIdempotencyKey(crypto.randomUUID(), fn));
+    return ok(await fn());
   } catch (e) {
     return err(problemDetail(e, fallback));
   }
 }
 
+/**
+ * `runResult` for a **mutating** call: also mints the Idempotency-Key for this
+ * logical submit — once per `runSubmit` call, not per HTTP attempt — so a
+ * retry of this same submit dedupes on the backend (see `withIdempotencyKey`).
+ * Reads must go through `runResult` instead, which mints nothing.
+ */
+export function runSubmit<T>(fn: () => Promise<T>, fallback: string): Promise<Result<string, T>> {
+  return runResult(() => withIdempotencyKey(crypto.randomUUID(), fn), fallback);
+}
+
 // Single shared default for a failed submit; the @@id dedupes it at the
 // translation layer.
 export const SUBMIT_FAILED = $localize`:@@submit.failed:Het indienen is niet gelukt. Probeer het later opnieuw.`;