Add screenplay generate and validate commands

[woksin]

Added

• cratis screenplay generate produces a Cratis Screenplay .play document from the source of an Arc application, without running it (Add 'cratis arc screenplay' to fetch a .play file from a running Arc application #44)
• cratis screenplay validate compiles .play files and reports their diagnostics, exiting non-zero when any are errors

Fixed

• Projects whose resource classes are generated during the build are read correctly, instead of appearing not to compile (screenplay generate: run source generators when loading the compilation and write the document even when generation reports errors #49)
• The generated document is written even when generation reports errors, so a partial result can be inspected rather than lost (screenplay generate: run source generators when loading the compilation and write the document even when generation reports errors #49)

[woksin]

Reviewer context — deliberately kept out of the description.

This is agent-authored code that no human has read yet. Please treat the spec suite as a claim to be checked rather than as evidence on its own. The areas I would look at first are ScreenplayCompilationLoader/DesignTimeResourceGeneration (the MSBuild hook is the sharpest edge in the change) and whether the new validate specs assert meaningful behaviour rather than merely existing. Do not merge without explicit sign-off.

What this depends on. Cratis.Arc.Screenplay 20.65.0, published earlier today from Cratis/Arc#2384. The branch previously reached the generator through an opt-in CratisArcScreenplayProject MSBuild property; that scaffold is now removed entirely, along with UnavailableScreenplayGeneration and the CLI0005 diagnostic that existed only to say the generator was unavailable. Cratis.Screenplay resolves to 1.5.2, which is exactly what the package depends on — a mismatch there fails assembly load at runtime.

The resx fix, and what it is not. A design-time build only runs the Compile target, and $(CompileDependsOn) does not include PrepareResources — that chain is a sibling of Compile inside CoreBuild. So strongly-typed .resx designer classes were never generated and never entered @(Compile), and an ordinary application presented as 605+ missing-symbol errors. The fix injects a targets file through CustomAfterMicrosoftCommonTargets that runs PrepareResources before CoreCompile, which is where a real build runs it. Nothing is hard coded, and it works on a project that has never been built — verified by deleting all 13 generated files from the test application and re-running. A narrow fallback that re-adds already-generated files from the intermediate output is kept for a read-only obj/, and is a no-op whenever the hook works.

#49 also floated replacing MSBuildWorkspace with dotnet msbuild -getItem. That was deliberately not done here: the hosting model is worth deciding on its own merits rather than as a side effect of a bug fix, and it is filed separately as #50 with the single-file/Homebrew MSBuildLocator rationale.

Three things a reviewer may want to change

• validate exits 5 (ExitCodes.ValidationError) on a rejected document, where the official Cratis.Screenplay.Tool exits 1. Both report the same errors at the same positions; only the code differs. Following this CLI's own exit-code taxonomy seemed right, but it is a visible difference.
• GeneratedScreenplay.Failed is now unused in production code — its only caller was the deleted UnavailableScreenplayGeneration. Left in place as a public factory mirroring LoadedCompilation.Failed; easy to remove if you would rather not ship it.
• ScreenplayDiagnosticsWriter now omits the code when it is empty. The Screenplay compiler assigns no diagnostic codes, and I did not want the CLI inventing a taxonomy for them. generate output is unchanged, since its codes are never empty.

Verification

• Cli.csproj Release with no -p:CratisArcScreenplayProject: 0 errors, 0 warnings. Full solution clean build: 5 projects, 0/0.
• 355 specs passing (313 before; the merge from main brought 5 of those).
• Each of the seven commits was built in isolation in a detached worktree — 0/0 every time.
• End to end against a real production application (~1,800 syntax trees), no harness and no project reference: generate exits 0 and writes a 5,370-line document with no SP0024 and zero error-severity diagnostics; a second run is byte-identical. validate on that document exits 0 with one warning, and the official Screenplay tool reports the same thing — 0 errors, 1 warning. On a deliberately broken document both report the same two errors at the same positions.
• origin/main merged in (ten commits, no conflicts — the two lines of work touch disjoint files).

Known, pre-existing and not introduced here: Documentation/verify-markdown.sh does not pass on this repo and did not before — 725 issues across 33 files, mostly MD013 line length and MD060 table pipes. The new page carries the same classes every other file does and adds no new violation categories.