Postprocessor frames + IUsesServiceProviderFrame hook on ScopedContainerCreation (#385)

[jeremydmiller]

Implements #385: a first-class extension point on the frame that emits the scoped-container line (await using var serviceScope = ...) so Wolverine can register frames guaranteed to run immediately after the scope line and before anything else in a generated method body.

Changes (in JasperFx)

• IScopedContainerCreation (public) — void AddPostProcessor(SyncFrame frame). ScopedContainerCreation stays internal and implements it; consumers reach the live instance via the scoped IServiceProvider variable's Creator:

  if (scopedProviderVariable.Creator is IScopedContainerCreation scoped)
      scoped.AddPostProcessor(myFrame);

• IUsesServiceProviderFrame (public marker) — void UseServiceProvider(Variable serviceProvider). In FindVariables, the parent hands its scoped provider to each such child before the child resolves its own variables, so the child never asks the arranger for an IServiceProvider (the scope line is itself the creator of that variable → bi-directional dependency).
• GenerateCode chains the postprocessors (CompositeFrame-style) after the scope line and before Next, in registration order. The GetServiceFromScopedContainerFrame emits 'await using' without promoting the host method to async #228 AsyncMode == AsyncTask await using gate is unchanged.
• Creates surfaces the postprocessors' created variables (plus Scope/Scoped) so downstream Next frames can consume them.

Re-parent decision (issue's open question #4)

The plan proposed surfacing child variables without re-parenting (Creator stays the child), matching CompositeFrame, with the guard test as the decision point. That approach recurses infinitely: the arranger resolves the downstream consumer via the surfaced variable, sees its Creator is the nested postprocessor (not a top-level frame), inserts that postprocessor as a duplicate top-level frame, and chains it back into the scope frame's own postprocessor emission → StackOverflow.

Fix (the documented fallback): Creates re-parents each surfaced variable to the scope frame via a new internal Variable.OverrideCreator (sets the creator with no creates-list side effect). Downstream ordering then points at the top-level scope frame and nothing is double-inserted.

Acceptance criteria

• Postprocessors emit after the scope line and before Next, in registration order (async + sync)
• IUsesServiceProviderFrame postprocessors receive the scoped provider and emit against it with no second scope / no cycle
• Variables created by postprocessors are visible to downstream Next frames and resolve through the arranger (the guard test — proves the re-parent decision)
• A postprocessor's own dependencies resolve via the normal FindVariables path
• No postprocessors → byte-identical output; full suite green incl. GetServiceFromScopedContainerFrame emits 'await using' without promoting the host method to async #228 ScopedContainerCreationTests

Tests (src/CodegenTests/Services/ScopedContainerCreationPostprocessorTests.cs)

Emitted order (async/sync), provider hand-off + no-second-scope, the downstream-consumer arranger guard, a postprocessor's own dependency resolution, and the byte-identical regression. Full suite: CodegenTests 367, CoreTests 439, CommandLineTests 285, EventTests 302 (net9/net10) + AOT smoke, all green.

Out of scope

The Wolverine-side postprocessor frames + registration (tracked in the Wolverine repo), and any C#/F# emission-split (#383).

🤖 Generated with Claude Code