Fix runtime injection for decorated Blade engines

[prateekbhujel]

Summary

This fixes a regression in v1.0.3 where Blaze runtime injection can be skipped when the Blade engine is wrapped by a decorator (for example Sentry's ViewEngineDecorator).

What changed

• Resolve wrapped/decorated view engines by unwrapping getEngine() until a CompilerEngine is found
• Keep the existing guard so non-Blade engines still do not receive __blaze
• Add a regression integration test that wraps the blade engine and verifies rendering does not fail

Why this is needed

In the current code, registerBlazeRuntime() only checks instanceof CompilerEngine on the top-level engine object. Decorators are not CompilerEngine, so __blaze is not injected and compiled views can fail with Undefined variable $__blaze.

Verification

• Added test: injects blaze runtime when blade engine is decorated
• Full test suite passes locally (vendor/bin/pest)

[prateekbhujel]

I reproduced the regression with a decorated Blade engine and confirmed the undefined __blaze failure before this patch.

Validation steps I ran locally:

• Added a regression test that wraps the blade engine in a decorator implementing getEngine()
• Confirmed failure before fix: Undefined variable $__blaze
• Confirmed pass after fix: decorated engine path now injects runtime correctly
• Ran full suite: vendor/bin/pest (all green)

[ganyicz]

Hi @prateekbhujel

Thanks for contributing however this feels like a very hacky solution.

[prateekbhujel]

Thanks for the candid feedback. You’re right that this approach adds too much complexity for this path. I’ll leave this here and won’t push further changes on this topic.