[Arch/Design] Internal provision event handlers fire per-layer instead of once

[rajeshkamal5050]

When using infra.layers, our internal handlers registered via projectConfig.AddHandler fire once per layer instead of once for the whole provision.

Today this is harmless - the two handlers (container apps RESOURCE_EXISTS check, AKS kube context setup) are both idempotent. But architecturally it does not match the deploy model where root handlers wrap everything once.

User-facing hooks (YAML) are not affected - project-level hooks fire once via middleware, layer hooks fire per-layer by design.

This came up during PR #7382 review. We should align the internal event handler model with deploy before more handlers get added.

Ref: #7382 (comment)

[wbreza]

Thanks @rajeshkamal5050 for filing this to track the discussion from PR #7382. It was a good call to separate the architectural question from the feature work.

After doing a deep investigation of the hooks and event architecture, here's what we found:

The provision event model has two separate execution paths:

Level	Mechanism	Fires Per Layer?	Status
Project command hooks	HooksMiddleware → HooksRunner	No — once per command	✅ Working correctly
Layer hooks	runLayerProvisionWithHooks() → HooksRunner	Yes — by design	✅ Working correctly
Internal Go handlers (container apps, AKS, extensions)	projectConfig.Invoke() → EventDispatcher	Yes — per layer	✅ See below

User-facing YAML hooks and internal Go event handlers are completely separate systems. YAML hooks use HooksRunner for direct script execution. Internal handlers use the EventDispatcher event bus. They share the preprovision/postprovision naming but never interact.

On the per-layer firing of internal handlers: The ProjectLifecycleEventArgs already includes "layer" (name) and "path" in the event args. Handlers that need to differentiate between root-level and layer-level provisioning can inspect the "layer" arg. Both existing handlers (container apps RESOURCE_EXISTS and AKS kube context) are idempotent and function correctly with per-layer timing.

We also evaluated whether layers should get their own EventDispatcher for consistency with the service model, and concluded it's not warranted — provisioning.Options is a value type with copy/merge semantics that are incompatible with an embedded event bus, and there are no consumers that need layer-scoped event dispatch today.

Recommendation: No architectural changes needed at this time. The current model is sound. If future handlers require root-vs-layer awareness, the "layer" arg in the event args already provides that capability. Proposing we close this issue.