docs(spec): application-profile: dispatch record covers resreq; removed profile makes jobs pend

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

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

@@ -355,11 +355,20 @@ Not part of this spec, recorded here because they replace profile defaults:
   essentials, queue ceilings and project quotas still apply at submit.
 
 ### Dispatch record
-Decided 2026-10-12 (user): execution-side values are **frozen at dispatch**.
-- At each dispatch the controller reads the job's profile and puts the
-  effective execution values (mode, mode options, launch type, env, outer
-  pre/post-exec, limits) into the job's `start_info` for the worker, **and**
-  into an additive payload on the WAL dispatch fact
+Decided 2026-10-12 (user): what a job was scheduled and started with is
+**frozen at dispatch**. A pending job follows the current profile; a
+dispatched job uses only its dispatch record until it is requeued or
+restarted, and the scheduler no longer re-merges it.
+- The record holds both sides:
+  - scheduling: the effective resreq (`select`, `rusage`, `span`, `same`,
+    `order`) and task count, so a running job's reservations (e.g.
+    `rusage[license=1]`) do not change when the profile changes, and are
+    rebuilt identically after a scheduler failover or restart;
+  - execution: mode, mode options, launch type, env, outer pre/post-exec,
+    limits.
+- At each dispatch the controller puts the execution values into the job's
+  `start_info` for the worker, and the whole record into an additive
+  payload on the WAL dispatch fact
   (`persist_submit_job_dispatch_fact`, `controller/persist.c:8167`) and the
   snapshot. Both apply seams decode it; `/xce-audit-invariants` checks the
   round trip.
@@ -371,6 +380,28 @@ Decided 2026-10-12 (user): execution-side values are **frozen at dispatch**.
   "profile changed since dispatch" when the current profile differs.
 - **Requeue or restart re-reads the profile** at the next dispatch, the same
   as the live merge does for pending jobs.
+- Running jobs therefore need nothing from the live profile: post-exec at
+  the end, later remote tasks or a resize, and a service replica's probes
+  and in-place restarts all use the record.
+
+### Profile removed while jobs use it
+Decided 2026-10-12 (user): **a job whose profile no longer exists pends**,
+with the reason "application profile X is not defined".
+- This applies to every job that reads the profile: pending jobs, requeued
+  or restarted jobs, and new service replicas (replacements, scale-up),
+  which are new jobs. Running jobs are unaffected (dispatch record); a
+  service whose profile is gone keeps its running replicas but shows as
+  degraded when one cannot be replaced.
+- Putting the profile back releases the jobs. A rename is remove plus add.
+- The removal is never refused (`xceadmin config build` works offline and
+  cannot know live jobs) and jobs never exit because of it.
+- The controller's live-upgrade reply lists removed profiles still named by
+  pending jobs or services, with counts; `xceadmin config upgrade` prints
+  it. Needs a new scheduler pend reason (profile missing from
+  `Conf4Sched`).
+- Leaning, for requirements: `jobmod --app <new>` moves a pending job to
+  another profile (the owner, with `app:use` on the new one; admins in bulk,
+  e.g. `--app-from <old>`); the scheduler re-evaluates.
 - Why: for sandboxed jobs the mode and mounts a job actually ran with is a
   security/audit fact, and `job-sandbox-execution`'s mandatory cleanup
   depends on it; `persistence.md` does not allow memory-only state without a
@@ -432,19 +463,17 @@ Decided 2026-10-12 (user): execution-side values are **frozen at dispatch**.
   - ~~How resource defaults combine with a job's own resreq~~ — settled
     2026-10-09, owned by `job-config-merge`.
   - Profile versioning and audit.
-  - Whether the profile can be changed for a pending job (leaning yes:
-    re-check `app:use`, store the new name, the scheduler re-evaluates).
+  - `jobmod --app` for a pending job: who may, and the bulk form (leaning:
+    the owner with `app:use` on the new profile; admins in bulk).
   - Raised 2026-10-12, not yet decided:
-    - Removing a non-default profile that pending jobs still name (leaning:
-      xceadmin warns, the jobs pend with "profile X not defined", running
-      jobs continue).
     - A denylist of env variables a sandbox profile forbids jobs to add
       (e.g. `LD_PRELOAD`)?
     - 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: execution values frozen at dispatch, re-read on
-    requeue ("Dispatch record"); override granularity (no markers; additive rule),
+  - 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"); override granularity (no markers; additive rule),
     limits a job may lower (profile limits are maximums), personal presets
     (client side), `app:override` and inheritance (deferred).
     - Splitting the spec: execution mode, I/O directories, capability