docs(spec): resource control under the project tree; retire limits.yaml

The project tree is the only place concurrent use is capped: quotas are
written on the project (quota, member_quota over the subtree) and compiled
into the limit plugin, which becomes internal. Queues keep per-job
ceilings only; host slot caps are supply. Project path is the identity
and the only submit form; members are users and user groups, never
sub-projects. Adds the limits-to-owners backlog item.

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

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

@@ -293,8 +293,8 @@ fits XCE's LSF-style job model.
     (`app-access-control`).
   - Resource values in a profile describe what the application needs (its
     essential resource requirement and per-job execution limits). They are
-    not scheduling policy. Queue-level scheduling limits keep applying on top,
-    unchanged.
+    not scheduling policy. Queue per-job ceilings and project quotas check
+    the merged result on top (no queue aggregate caps, 2026-10-12).
 - **Live merge** (`job-config-merge`). The job records its profile name and
   its own values, not the effective values. The scheduler computes the
   effective values and recomputes them when the profile changes: a pending job
@@ -501,7 +501,7 @@ resreq:
   grammar.
 - Consequence: `rusage` is the one profile part that holds **defaults**; a
   profile cannot enforce a minimum reservation. Hard protection of shared
-  resources comes from `limits.yaml` and project quotas.
+  resources comes from project quotas (`limits.yaml` is retired, 2026-10-12).
 - Side effects to handle in requirements: measured resources (memory) are
   charged `max(reserved, actual)` once usage is reported
   (`resource-accounting.md`), so lowering them mostly self-corrects, but