docs(sandcastle): decomposer + reviewer enforce vertical-slice tasks

The user surfaced that the binder-wrap-helper epic's stories
decomposed into horizontal sub-steps (read 3 files → write helper
→ write test → export → typecheck → coverage), not vertical
slices. Per the glossary's slice = task = PR = commit rule, every
checkbox should land as one green commit.

.sandcastle/decomposer.prompt.md:
  - New "The slice rule (non-negotiable)" section near the top
    defining the three constraints every task must satisfy: one
    green commit; exercises a layer; independently meaningful.
  - New "Tasks that are FORBIDDEN" list naming the anti-patterns
    the previous output exhibited (read a file as a task; write
    test without impl; standalone gate runs; standalone export;
    sub-step decomposition of a single slice).
  - New "Tasks that are CORRECT" list with examples drawn from
    this codebase (gen invocation, full use-case slice, per-feature
    binder migration, audit emission, bindAll wiring).
  - New paragraph on "Manifest-first ordering INSIDE a task" —
    the 4-step ordering (manifest → contracts → red test → green
    impl) is what the implementer does within one task, not a
    multi-checkbox decomposition.
  - Constraints section gains two new bullets:
      * Prefer FEWER but FATTER tasks (one per vertical slice)
        over MANY thinner sub-steps
      * Self-check: imagine the commit each checkbox produces;
        do all gates pass on that commit alone?

.sandcastle/reviewer.prompt.md:
  - New check #8 "Slice discipline" rejecting:
      * Multi-commit diffs where any intermediate commit has red
        gates
      * Sub-step shape that should have been separate tasks
      * Incomplete slices (use case w/o DI binding, manifest
        publish w/o publish site, controller w/o router wiring)

.gitignore: adds `.pnpm-store/` so a misconfigured pnpm install
that places the store inside the project doesn't stage thousands
of cache files.

The existing binder-wrap-helper stories were decomposed under the
old (unconstrained) prompt and need re-decomposing under the new
rule. That's a separate action — this commit fixes the prompts;
the existing epic stays as-is until you re-decompose.

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

.sandcastle/reviewer.prompt.md

@@ -36,6 +36,10 @@ If you suspect the implementer hand-rolled what should have been generator outpu
    - **Per-layer thresholds (L0)**: any new code under `entities/`, `application/use-cases/`, or `interface-adapters/controllers/` is bound to 100%/100%/95%/100% bands. If the test run produced threshold errors, that's a rejection.
    - **No silent allowlist expansion**: if `scripts/coverage/diff.mjs`'s `ALLOWED_GLOBS` grew, the implementer's notes must explain why (and the matching test fixture must exist in `scripts/coverage/diff.test.mjs`).
    - **Manifest coverage band drift**: if `feature.manifest.ts` was edited, its `coverage:` section must match `DEFAULT_COVERAGE_BANDS` from `@repo/core-shared/conformance/coverage` (or carry an explicit override the implementer's notes justify).
+8. **Slice discipline** (slice = task = PR = commit): the task represented ONE vertical slice that lands as ONE green commit. Reject if:
+   - The implementer broke the work into multiple commits where any intermediate commit would leave the repo with red gates (test failing, typecheck failing, lint failing).
+   - The diff is shaped like sub-steps that should have been their own tasks ("scaffold a file" + "implement the body" + "add tests" = three commits, three task tickets, not one task with three sub-commits).
+   - The slice is incomplete — e.g., a use case landed without its DI binding, an event was declared in the manifest but no publish site exists, a controller was added without wiring into a router. The slice is whole or it's a rejection.
 
 ## Epic close-out: PRD status flip