26.09.1 — response schemas, an error page, a dashboard that browses your data, and five security fixes

…thing

Tagging v26.09.1 ran the split and all 28 jobs went green. No mirror repository existed and nothing
was published: symplify/monorepo-split-github-action prints "Command failed" and exits 0, so the
failed clone of a non-existent destination cost the job nothing. A release pipeline that reports
success without shipping is worse than one that fails, because nobody goes looking.

Two guards, since the action's own exit code cannot be trusted:

- a preflight job that fails the run once when ACCESS_TOKEN is unset, pointing at the runbook,
  rather than letting 28 credential-less jobs pass;
- a per-package step that reads the tag back from its mirror through the GitHub API after the
  split, and fails when it is not there. Verification has to come after the push to mean anything,
  so the test asserts the ordering too.

docs/publishing.md carried the same trap it documents: step 5 pushed `main --tags`, firing the split
before step 6 created the mirrors — the exact sequence that just happened here. The branch and the
tag are now pushed in separate steps, with the mirrors created in between.

ReleaseWorkflowTest passed throughout the incident because it checked the matrix and the trigger, not
whether a failure could be noticed. Both guards are now pinned by tests; each was verified by
reverting the guard and watching its test fail.

Claude-Session: https://claude.ai/code/session_01MCTyVciS2A5pfPv5xAthPd

Every one reproduced by a failing test first.

- cqrs: CommandProcessingException/QueryProcessingException dropped the cause's
  errorCode while copying its httpStatus, category and severity, so every domain
  fault reached the client as COMMAND_PROCESSING_ERROR and callers had nothing to
  branch on. BREAKING.
- container: ContainerRegistrar rebound every #[Component] class unconditionally
  during boot(), silently discarding a binding the application had registered in
  register(). The failure surfaced later as an unrelated-looking autowiring error.
  Explicit bindings now win, matching the bean sweep's own precedence rule. BREAKING.
- security/context: strict method security refused the boot of `firefly:cache`
  itself, so the command its own error message told you to run could never run.
  AppScan::regenerating() now reports that boot and the gate stands down for it.
- context: a stale compiled manifest killed EagerSingletonsPass before
  `firefly:cache` could replace it, leaving `rm -rf bootstrap/cache/firefly` as the
  only recovery. Compiled artefacts are ignored while regenerating.
- skeleton: `/tests export-ignore` deleted the test scaffold from every scaffolded
  project, so a fresh `composer create-project` fatalled on a missing
  Tests\CreatesApplication trait before running one assertion.

Release 26.09.2.

Co-authored-by: Andres Contreras <andres.contreras@soon.es>

…plit

Per docs/publishing.md step 4: the tagged commit must carry stable sibling
constraints, not the *@dev path constraints local development uses, so each
Packagist mirror is installable on its own under the default
minimum-stability: stable. The tree is restored to *@dev immediately after
the tag is cut (step 8).

docs/publishing.md step 8. The v26.09.2 tag carries the ^26.09 constraints the
split needs; main goes back to the path-repository constraints local development
and the test suite resolve against.