docs(steering): one owner per job attribute; pre/post-exec moves to the app profile

New steering job-config-layering.md: queue = scheduling policy, application
profile = what the application needs and how it runs (resreq, task range,
execution settings, pre/post-exec, limits), project = resource ownership.
Only two interactions: the job overrides a profile attribute marked
default (fixed: not at all; select: only ANDed terms), and queue ceilings
or project quotas check effective values (reject if never satisfiable,
pend if full now). Replaces the simplified job > app > queue rules.

Queue pre_exec/post_exec are deprecated with queue res_req: the profile's
pre/post-exec fills the worker's existing outer layer, the job's own stays
the inner layer, allowed or forbidden by the profile.

job-config-merge and application-profile briefs and the roadmap follow;
CLAUDE.md lists the new steering file.

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

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

@@ -13,10 +13,18 @@ decisions):**
   requirement* (select / rusage / `span[...]` / same) and task limits
   (min / default / max, LSF TASKLIMIT), **project** = resource ownership
   (`project-config`).
-- How the levels combine is owned by **`job-config-merge`**: job overrides
-  profile section by section, `select` is ANDed, queue hard and task limits
-  are ceilings that reject. This answers the open question "how resource
-  defaults combine with a job's own resreq" below.
+- Every attribute has one owning level (`.kiro/steering/job-config-layering.md`).
+  How the levels interact is owned by **`job-config-merge`**: each profile
+  attribute is *default* (the job may replace it) or *fixed* (the job may
+  not; for `select` it may only add ANDed terms); queue ceilings and project
+  quotas only check, never change, the job's values. This answers the open
+  question "how resource defaults combine with a job's own resreq" below.
+- **Pre/post-exec moves here from the queue** (queue `pre_exec`/`post_exec`
+  deprecated). The profile's pre/post-exec is admin-defined and always runs
+  as the outer layer; the job's own pre/post-exec is the inner layer, allowed
+  or forbidden by the profile. Order: profile pre → job pre → job → job post
+  → profile post (the worker's existing two-layer structure,
+  `xcecd_worker.c` `queue_pre_exec()`/`queue_post_exec()`).
 - **Replaces "Resolution at submit time"** below: the merge is *live*. The WAL
   keeps the job's own values plus the profile name; the controller and
   apiserver validate at submit, and the scheduler computes effective values