#3320 fix: compile-check says why it compiled an assembly in full instead of checking only the changed files

Summary

• When compile-check compiles an assembly in full instead of checking only its changed files, the reason now says what to do about it: whether the last full compile had errors, which kind of input changed, and how many files changed against the limit.
• The docs explain when the first body edit is still compiled in full (right after a Unity build, after a --full with errors, after a run that skipped or blocked the assembly, and after --all in an assembly that references another of the project), and why UncheckedCodes can list fewer codes than the docs name.

User Impact

• Before: testers saw no baseline from an earlier full compile right after a --full that had errors, although earlier full compiles had succeeded, and inputs other than source contents changed after --all without any hint that --all caused it. Both had to be worked out by comparing logs.
• After: the reasons read, for example, no baseline: the last full compile had errors, inputs other than source contents changed: references, and too many changed files (32, limit 30). Which assemblies are checked and what they report does not change.

Changes

• A missing baseline is told apart by the manifest of the last full compile: it had errors, it succeeded but recorded none, no full compile is on record (none ran, or a later run skipped or blocked the assembly, which removes its result too), or the baseline was written by another version. Unreadable non-source inputs have a reason of their own.
• The non-source key is digested per kind of input (compiler, response file, source list, references, analyzers, analyzer inputs, output name), and the baseline keeps those digests, so the fallback and the baseline note name what changed. The baseline format version goes to 3, so existing baselines are replaced by one full compile. The input key keeps its exact bytes (pinned by a test), so recorded results stay reusable.
• too many changed files gives the count and the limit.
• docs/compile-check.md and the compile-check skill (6,644 bytes) describe the reasons and the cases above. UncheckedCodes leaves out codes the response file turns off and disabled analyzer rules, which the worker already did.

Verification

• cli/dispatcher: golangci-lint fmt --diff, go vet ./..., golangci-lint run (0 issues), the complexity config (0 issues), and go test ./... pass. Coverage with the CI exclusions: 94.15% (baseline 94.2).
• cli/release-automation: go test ./... passes, including the architecture test on file length.
• File length, skill size, and scripts/sync-tool-docs.sh --check pass.
• Mutation checks, each restored afterwards: treating a failed full compile like any other missing baseline fails TestFailedFullCompileLeavesNoBaseline; naming no changed kind fails TestNonSourceKeyMismatchFallsBack, TestNonSourceInputChangedDuringCompileLeavesNoBaseline, and TestNonSourceKeyChangesWithReferenceAndRsp; removing the unreadable-inputs reason fails TestUnreadableNonSourceKeyFallsBack. TestBaselineRemovedByBlockedRunIsNotCalledNeverCompiled pins the reason after a blocked run. Coverage after the review fixes: 94.16%.