docs(spec): presets record themselves in exdata.meta; job-labels backlog item

- no preset field on the server: the client puts preset name + hash into
  the job's exdata JSON under 'meta', passed through uninterpreted; the
  worker skips 'meta' silently; 'preset report' filters jobs client-side
- drop the local submission log idea
- job-labels: independent backlog item (general server-side labels)
- bug-1970: note the dropped REST 'tags' field

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

.kiro/specs/application-profile/brief.md

@@ -572,10 +572,6 @@ Decided 2026-10-12 (user), so a rename never strands jobs:
 - **Open for requirements**:
   - ~~How resource defaults combine with a job's own resreq~~ — settled
     2026-10-09, owned by `job-config-merge`.
-  - Raised 2026-10-12, not yet decided:
-    - Job labels (`--label key=value`, e.g. the preset name) and a summary
-      grouped by label, to compare tuning variants: here,
-      `job-status-detail-display`, or `xcecli-presets`?
   - Settled 2026-10-12: scheduling and execution values frozen at
     dispatch, re-read on requeue ("Dispatch record"); a removed profile
     makes its jobs pend ("Profile removed while jobs use it"); clean env for
@@ -586,7 +582,9 @@ Decided 2026-10-12 (user), so a rename never strands jobs:
     split into `job-sandbox-execution`; v1 attributes are the four plus the
     job starter, others ship with their job features; profile history and
     change audit deferred to the roadmap (`config-history-audit`): the
-    content hash and the dispatch record already show what each run used.
+    content hash and the dispatch record already show what each run used;
+    no job labels needed here (presets record themselves in `exdata.meta`;
+    general labels are the `job-labels` backlog item).
 - **Out**:
   - The `sandbox` mode and its options, I/O directories, capability
     advertisement, placement by mode and the worker sandbox mechanics

.kiro/specs/xcecli-presets/brief.md

@@ -122,8 +122,35 @@ configuration level.
 - **Safety and visibility:** a warning on export/import when env variable
   names look like secrets; `xcecli jobs submit --dry-run` shows the expanded
   options and the effective values after the profile merge
-  (`job-config-merge`); optionally the preset name is recorded as a job
-  label (`preset=<name>`) for comparing variants.
+  (`job-config-merge`).
+- **No preset field on the server; preset identity in `exdata.meta`**
+  (user, 2026-10-12). Expansion is entirely client-side and the server sees
+  ordinary job options. To compare variants, the client adds one opaque key
+  to the job's exdata JSON:
+
+  ```json
+  { "sub_env_vars": {...}, "limits": {...},
+    "meta": { "preset": "cfd-team/openfoam-large", "preset_hash": "3f2a9c" } }
+  ```
+  - exdata already round-trips with no schema change: client →
+    `start_info.exdata` → WAL submit fact and snapshot → worker, and job
+    queries return it as `extend_data` (`apiserver/backend/convert_pure.go`
+    :388, :537); 16 KB cap (`maxExdataLen`, :395).
+  - `meta` is client-only metadata: apiserver and controller pass it
+    through uninterpreted. The worker's `parse_exdata()`
+    (`worker/src/xcecd_exdata.c`) ignores unknown top-level keys but logs a
+    NOTICE for each; this spec makes `meta` a known, silently skipped key
+    (one-line worker change).
+  - `xcecli preset report <name>` lists the user's jobs through the normal
+    API and filters on `extend_data.meta.preset` client-side: runtime, peak
+    memory, efficiency and exit status per preset or preset version. It
+    covers jobs from any login node, and the portal when it writes the same
+    key. No local submission log.
+  - Limits: the server cannot filter or index `meta`, so the report fetches
+    and filters the user's jobs (fine for personal tuning); `meta` is
+    whatever the client wrote, informational only, never trusted.
+  - Server-side labels for filtering and team-wide grouping are a separate,
+    general feature (`job-labels`, backlog).
 - **Portal:** the same expansion (a small option-level merge) and the same
   read-only listing; its personal presets are stored by the portal itself
   and are not shared with xcecli in the first version.
@@ -131,13 +158,13 @@ configuration level.
 ## Scope
 - **In:** preset format, xcecli commands, expansion and precedence, the
   read-only apiserver listing/fetch and its file directory, pull/diff,
-  export/import, secret warning, dry-run display, tests.
+  export/import, secret warning, dry-run display, `exdata.meta` and
+  `preset report`, the worker's `meta` skip, tests.
 - **Out:** writable server-side shared presets (would need owners,
   visibility and durable storage; revisit only if the portal needs it, after
   `rbac-persistence`), automatic application of presets, any server-side
   preset expansion.
-- **Open:** whether the preset-name label lives here or in
-  `job-status-detail-display` (job labels); the portal's preset storage.
+- **Open:** the portal's preset storage.
 
 ## Upstream / Downstream
 - **Upstream:** `application-profile` (profiles and `--app`),