Thread blade compiler instance through pipeline

[ganyicz]

The scenario

Running php artisan optimize with Sentry installed produces broken compiled templates — components aren't compiled to functions.

The problem

During php artisan optimize, Laravel runs multiple commands sequentially:

1. The config:cache step swaps the application instance in the container.
2. When view:cache runs next, the blade compiler doing the compilation belongs to the original instance.
3. Now, calling app('blade.compiler') anywhere resolves from the new instance which is different from the one actually doing the compilation.

This only happens if the blade engine was resolved before view:cache runs. Without the early resolution, Laravel would compile views using the blade compiler from the new app instance. Any package can trigger this early resolution — Sentry does this while decorating the blade engine.

The blade compiler carries state — current path, raw blocks, etc. — that we rely on throughout compilation.

In #43, app('blade.compiler')->getPath() returned null because it resolved the wrong instance, causing downstream bugs.

The solution

The immediate fix was shipped in #88.

This PR prevents the entire class of issue by ensuring Blaze always uses the same blade compiler instance throughout compilation.

We refactored BladeService from a static utility class into a singleton that receives the blade compiler via constructor injection. That instance is threaded through the entire pipeline — no class resolves app('blade.compiler') from the container anymore. This required widescale refactors to decouple classes that previously depended on BladeService or resolved the compiler themselves.

Added an integration test that verifies no class resolves blade.compiler from the container during compilation.

[github-actions]

Benchmark Results

Attempt	Blade	Blaze	Improvement
#1	377.94ms	19.67ms	94.8%
#2	375.48ms	19.54ms	94.8%
#3 *	379.26ms	20.20ms	94.7%
#4	375.17ms	19.50ms	94.8%
#5	378.05ms	19.49ms	94.8%
#6	379.98ms	19.56ms	94.9%
#7	378.04ms	19.61ms	94.8%
#8	380.90ms	19.87ms	94.8%
#9	374.67ms	19.55ms	94.8%
#10	375.57ms	19.75ms	94.7%
Snapshot	379.17ms	19.61ms	94.8%
Result	377.94ms (~)	19.56ms (~)	94.8% (~)

_{Median of 10 attempts (* = outlier, excluded from result), 5000 iterations x 10 rounds, 49.93s total}