Improve FluxServiceProvider boot performance

[joshhanley]

The Scenario

FluxServiceProvider adds measurable overhead to every request's boot phase. One user reported 215ms, while our own benchmarking shows 6-11ms in the browser and a median of 5.5ms across 100 CLI cold-starts:

CLI (100 runs):
  Median:  5.46ms
  Mean:    5.61ms
  P95:     6.26ms
  Max:     11.49ms

Browser (4 refreshes):
  10.96ms, 9.96ms, 6.16ms, 6.18ms

The Problem

FluxServiceProvider is the first service provider to resolve blade.compiler during the boot phase. This triggers autoloading of Laravel's entire view layer (BladeCompiler, Compiler, Factory, FileViewFinder, EngineResolver, and the Blade facade) before any other provider has needed them.

On top of that, app('flux')->boot() forces autoloading of Livewire\Component just to register a modal macro, and the FluxTagCompiler is eagerly instantiated even though it's only needed when Blade actually compiles a view.

Most of the boot time (~10 of the 15 classes loaded) consists of core Laravel and Livewire classes that would be loaded anyway by Livewire's own service provider moments later. Flux just happens to trigger them first due to boot order.

The Solution

Three changes to defer work until it's actually needed:

1. callAfterResolving('blade.compiler', ...) - Instead of eagerly resolving the blade compiler (and triggering view layer autoloading), register a callback that fires when the compiler is first resolved by whoever actually needs it (typically Livewire). Component paths, directives, and the precompiler are all registered inside this callback.

2. $this->app->booted(...) - Defer bootMacros(), propertySynthesizer, and app('flux')->boot() until after all service providers have booted. These are only needed at render time, not during the boot phase.

3. Lazy FluxTagCompiler - The compiler is created on first Blade precompilation rather than eagerly during boot.

After the change:

CLI (100 runs):
  Median:  0.24ms
  Mean:    0.25ms
  P95:     0.31ms
  Max:     0.38ms

Browser (4 refreshes):
  0.38ms, 0.43ms, 0.30ms, 0.36ms

The total request time stays the same (the same classes are still loaded), but the cost is correctly attributed to the service that actually needs them rather than to Flux.

Fixes #1846