screenplay generate: run source generators when loading the compilation and write the document even when generation reports errors

[woksin]

Summary

Two compounding problems on branch feature/arc-screenplay make cratis screenplay generate produce no output at all for most real Arc applications:

1. ScreenplayCompilationLoader loads the project with MSBuildWorkspace and calls GetCompilationAsync(), which does not run source generators. Any application whose compilation depends on generated types — which includes every app following the Cratis house style ([LoggerMessage] partials, generated message-constant classes) — comes back with hundreds of missing-symbol errors, and Cratis.Arc.Screenplay raises SP0024 at Error severity.
2. GenerateScreenplayCommand.ExecuteAsync returns before writing the document whenever any Error diagnostic is present. So the user gets diagnostics and an exit code, but no .play file — even when the generated document is essentially complete.

Reproduction (real application)

Loading Ada (Core.csproj, ~1,800 syntax trees) via MSBuildWorkspace and calling the generator exactly as the branch does:

• 607 compilation errors, all missing source-generated types (first: The name 'AccountsMessages' does not exist in the current context);
• SP0024 [Error] The source did not compile - 607 error(s) … Nothing recovered from it describes the application reliably;
• yet result.Source was a 5,362-line document that compiles under the official Screenplay compiler with 0 errors / 1 warning and matches a known-good document for the same app almost byte-for-byte.

With the branch's current control flow, all of that is discarded.

Suggested fix

1. Run source generators in the loader: after GetCompilationAsync(), run the project's analyzer references through CSharpGeneratorDriver.RunGeneratorsAndUpdateCompilation(...) and hand the updated compilation to the generator. (PR Add Cratis.Arc.Screenplay package for generating Screenplay from Arc source Arc#2384 explicitly listed "does MSBuildWorkspace include generator output" as an unverified risk — it does not.)
2. Write the document even when generation reports errors (at least when --file is given): write the file, print the diagnostics, and exit non-zero. A 99%-complete document plus honest diagnostics is strictly more useful than nothing. Keeping stdout clean in the redirect case can stay as-is.
3. A companion issue on Cratis/Arc proposes calibrating SP0024's severity/wording so "607 errors, 5,300 lines recovered" is not reported as "nothing recovered reliably".

Relation to #44

#44 proposes fetching a .play from a running app (GET /.cratis/screenplay) and rejected offline generation on the grounds that fluent Define() artifacts need a live container. The merged generator reads fluent definitions statically (Roslyn source analysis), so that rejection no longer holds for the source route. The two designs are complementary (source = works from a checkout, nothing running; fetch = runtime fidelity, no SDK needed) — but the docs/README story should say which is canonical, and the fetch route's Arc endpoint does not exist yet.

Environment

• Branch feature/arc-screenplay (ScreenplayCompilationLoader.cs, GenerateScreenplayCommand.cs)
• Cratis.Arc.Screenplay 20.65.0 (now on NuGet — the conditional CratisArcScreenplayProject opt-in reference can become a plain PackageReference)

[woksin]

Correction on the mechanism (same reproduction, deeper analysis): the missing symbols are build-time-generated compile items — strongly-typed resource designer classes (*Messages.Designer.cs from .resx + GenerateResource) — not Roslyn source-generator output. Roslyn generators do run under MSBuildWorkspace (verified: Microsoft.Gen.Logging trees are in the compilation); what is missing is anything produced by build targets that the design-time build skips.

That changes the recommended fix for part 1: rather than a CSharpGeneratorDriver pass (which only covers Roslyn generators), prefer either (a) running a real dotnet build of the target before loading, or (b) skipping MSBuildWorkspace entirely and shelling out to dotnet msbuild -getItem:Compile,ReferencePathWithRefAssemblies after a build, then constructing the CSharpCompilation from those items — which sidesteps the whole class of design-time-build gaps and also avoids the MSBuildLocator-in-single-file-binary problem for the native Homebrew builds.

Part 2 (write the document even when generation reports errors) is unaffected.