[12.x] Add @includeIsolated directive for isolated Blade includes

[KennedyTedesco]

This PR introduces a new @includeIsolated Blade directive that includes a view without inheriting the parent scope's variables.

I work in a codebase where we use <x-component> for reusable components and @component() for partials (because we like variable isolation). However, @component() brings overhead we don't need: slot management, the opening/closing tag ceremony, and component lifecycle logic.

@includeIsolated would give us the best of both worlds: the simplicity of @include with the isolation of @component.

This PR is another shot of: #45616

Motivation

Currently, @include passes all parent scope variables via get_defined_vars():

{{-- Parent view has $user, $errors, $config, etc. --}}

@include('partials.hero', ['message' => $error])
{{-- hero.blade.php receives $message + ALL parent variables --}}

This implicit inheritance can lead to:

• Variable collisions in nested partials
• Unpredictable behavior when partials accidentally depend on the parent scope
• Harder debugging when variables "magically" appear

The recommended workaround is Blade components (<x-partials.hero />), but components come with overhead
(slots, validation, class resolution) that isn't always needed for simple partials.

Proposed Solution

@includeIsolated() provides explicit-only data passing where "explicit > implicit":

@includeIsolated('partials.hero', ['message' => $error])
{{-- hero.blade.php receives ONLY $message --}}

Benefits:

• Cleaner syntax for isolated partials (no closing tag needed)
• Lighter than @component (no slot/component machinery)
• Consistent with existing @includeIf, @includeWhen, @includeFirst patterns
• Prevents accidental variable leakage and naming collisions

[alies-dev]

this is great, @KennedyTedesco!!! Thank you so much!

[browner12]

love the isolation, and it's the reason I've basically only used components in our apps for many years.

when you talk about overhead on the components, are you talking about performance impacts? do these hits still exist when caching views?

[KennedyTedesco]

@browner12 Sorry, just saw your message now. The "overhead" (not a big thing, tbh) with components is primarily:

1 - Class instantiation (for class-based components): this still happens at runtime even with cached views
2 - Attribute bag/slot processing: the component infrastructure has more moving parts than a simple include

Honestly, the performance aspect is secondary for me. The main benefit is having a middle ground: I just want to include a partial, not render a component, but still get the isolation. Now that's possible.

[donnysim]

Nice! Though I have overridden blade compiler to disable it by default for everything, might think about using this instead. I find the original behavior bringing many unexpected and unwanted results with couple level deep includes, especially with forms.