docs(spec): application-profile v1 attributes: job starter added, others ship with their features

- v1 profile attributes: mode (direct), launch type, env + pre/post-exec,
  essential resreq and limits, plus the job starter
- principle: a profile attribute is added by the spec that builds its job
  feature; requeue/success exit values -> job-requeue (new backlog item),
  checkpoint and warning-before-kill later, output path -> I/O track,
  runtime estimate is not a profile attribute
- log bug-1970: REST submit accepts rerunable, requeue_error_values,
  run_time_estimation, mig_threshold, chkpnt_*, warning_* and drops them

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

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

@@ -167,8 +167,26 @@ fits XCE's LSF-style job model.
      order), its task range (min / max), and per-job execution limits as
      maximums (memory, runtime, CPU, tasks), mapped onto the existing worker
      cgroup limits.
+  5. **Job starter** (decided 2026-10-12): a wrapper the worker puts in
+     front of the job command (e.g. `module load openfoam &&`,
+     `apptainer exec img`), frozen on the dispatch record. Design decides
+     whether it wraps the MPI launcher or each task.
   All of these are essentials under the additive rule; none is a
   convenience default.
+- **A profile attribute ships with its job feature** (user, 2026-10-12): a
+  profile attribute is added by the spec that builds the job-level feature
+  it configures, never ahead of it, so no profile setting is dead config.
+  None of the other candidates exists as a job feature today, so they are
+  deferred:
+  - requeue exit values and success exit values: `job-requeue` (backlog);
+  - checkpoint method/period/directory, and a warning signal before the run
+    limit: their own future specs;
+  - output path template: the PR-6/PR-7 I/O track (output options are
+    rejected at submit today);
+  - runtime estimate: not a profile attribute at all (it describes one run:
+    a job option or preset; the profile's runtime limit is the maximum).
+  - Found on the way: the REST submit accepts several of these options and
+    silently drops them (bug-1970).
 - **Users pick a profile at submit** (REST, `xcecli jobs submit --app <name>`,
   harness, libxce). A **cluster default profile** applies when none is given.
 - **Jobs add, never override.** A job may add to its profile's values (more
@@ -552,9 +570,6 @@ Decided 2026-10-12 (user), so a rename never strands jobs:
     (shared with `job-config-merge`).
   - Tests.
 - **Open for requirements**:
-  - Which extra attributes go into v1 beyond the four ("maybe others"). Examples:
-    requeue exit values, runtime estimate, job starter or wrapper, output path
-    template, checkpoint settings.
   - ~~How resource defaults combine with a job's own resreq~~ — settled
     2026-10-09, owned by `job-config-merge`.
   - Profile versioning and audit.
@@ -569,7 +584,8 @@ Decided 2026-10-12 (user), so a rename never strands jobs:
     pending jobs deferred to `job-modify`, profile aliases in v1; override granularity (no markers; additive rule),
     limits a job may lower (profile limits are maximums), personal presets
     (client side), `app:override` and inheritance (deferred); execution modes
-    split into `job-sandbox-execution`.
+    split into `job-sandbox-execution`; v1 attributes are the four plus the
+    job starter, others ship with their job features.
 - **Out**:
   - The `sandbox` mode and its options, I/O directories, capability
     advertisement, placement by mode and the worker sandbox mechanics