docs(acl): describe the 008c8c0 layout checks and the platform-conf known limit

Task 2's fix round (008c8c0 on feat/app-manifest-lockdown) taught build.rs
to refuse any capability source command_census.rs can't see — non-top-level
capabilities/ entries, .toml/.json5, webviews/remote keys, inline
app.security.capabilities in any tauri config or TAURI_CONFIG — to name
which check failed, and to skip OS/editor junk. Documents those checks in
both capability descriptions and CLAUDE.md's Key Conventions, plus the
known gap that a new tauri.<platform>.conf.json only takes effect on a
clean or CI build.

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

CLAUDE.md

@@ -611,6 +611,18 @@ Anthropic and Bedrock deliberately keep Claude Code's own defaults.
   in a window imports a `tauri-commands.ts` wrapper that window is not granted. Only `_` becomes
   `-` in the identifier; `permissions/autogenerated/` is generated and ignored, and
   `gen/schemas/*.json` is regenerated by every build and committed.
+- **A new window needs its own top-level `capabilities/*.json`; never `webviews`/`remote`;
+  never inline.** `build.rs` only vouches for what `src/command_census.rs` reads — a top-level
+  `capabilities/*.json` file with a `windows` list — so it refuses to build on anything tauri
+  would load that the census can't check: a capability under a subdirectory or written as
+  `.toml`/`.json5`, a `webviews` or `remote` key in a capability file (either widens grants past
+  what `windows` says), `app.security.capabilities` declared inline in `tauri.conf.json`/any
+  `tauri.<platform>.conf.json`/`TAURI_CONFIG`, or a tauri config in a format it can't parse
+  (JSON5, TOML). OS/editor junk (`.DS_Store`, `Thumbs.db`, swap files) is recognised and skipped
+  rather than refused. Each failure names the check that failed, not just "capabilities do not
+  match generate_handler!". **Known limit:** adding a new `tauri.<platform>.conf.json` to a tree
+  that has already been built once only takes effect on a clean build or in CI — cargo's
+  incremental build has no reason to notice a file that did not exist on the previous build.
 - The `projects.json` file uses atomic writes (write to `.tmp`, then `rename()`). Corrupted files are backed up to `.bak`.
 - **Adding project state that changes the container?** `container_needs_recreation()` is entirely
   **label-based** — it does not diff the container's env. If a new setting affects the container's