fix(frontend): peek and restart take <array-id>[k] and written job IDs

- apiserver peek (parseJobIDParam): <array-id>[k] now resolves to the
  element; it used to drop [k] and look up the array identity itself
  (and panicked in parseArrayName on some inputs). A job number still
  names that job exactly (an element by its own XCE_JOBID); ranges and
  invalid selections are rejected.
- apiserver restart: the decimal-only pre-check (isValidJobId, now
  unused and removed) rejected the written form c-a-ts-seq[k];
  ParseIdentitySelection, already used for the lookup, validates it.
- xcecli jobs restart converts its argument with ToAPIJobID like the
  control commands, so written IDs work and invalid ones fail locally.
- docs: the peek/restart caveat in the Job arrays section.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

src/docs/xce.md

@@ -91,9 +91,10 @@ supports a subset of the LSF array syntax.
   - In listing and control commands, a bare element job number (for example
     the value of `XCE_JOBID`) is rejected: name the element as
     `<array-id>[k]`.
-  - `xcecli jobs peek` and `xcecli jobs restart` do not accept
-    `<array-id>[k]` yet: peek an element by its own job number
-    (`XCE_JOBID`); restart takes job IDs as before.
+  - `xcecli jobs peek` and `xcecli jobs restart` take one job: a job ID,
+    or one element as `<array-id>[k]` (not a range). `peek` also accepts
+    an element's own job number (`XCE_JOBID`). Restarting a bare array
+    identity is refused: restart one element at a time.
 - **Element number in the job's environment.** A running element finds its
   own number in `XCE_JOBINDEX` (1..N). An ordinary job gets
   `XCE_JOBINDEX=0`. A user-supplied `XCE_JOBINDEX` is overridden, with a