fix: prevent script dedup inside <template>

[seroperson]

Closes #15389

When a component with a script was first used inside a <template>, Astro's deduplication prevented the script from rendering outside the template, breaking non-template instances. This PR makes such scripts are not deduplicated. Should be merged after withastro/compiler#1156.

Changes

• Adds templateEnter / templateExit functions to be inlined by compiler inside of <template> tags. These functions add instructions that track <template> nesting depth during rendering.
• stringifyChunk skips dedup for scripts when templateDepth > 0. The script still renders inside the template but is also rendered outside for non-template instances.

Testing

Added astro-script-template-dedup integration test with four cases:

• Component used inside <template> first, then outside: verifies script appears in both places
• Component used outside first, then inside: verifies normal dedup still works
• Two components outside, then inside: verifies normal dedup still works x2
• Nested <template> elements: verifies depth tracking handles nesting

Docs

Docs aren't required as it's a bugfix.

[changeset-bot]

🦋 Changeset detected

Latest commit: 6202b78

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed-hq]

Merging this PR will not alter performance

✅ 18 untouched benchmarks

---

_{Comparing seroperson:i15389-template-script-dedup (6202b78) with main (3e7a9d5)}

[matthewp]

This is a very expensive change, for something that is a bit of a corner case. I don't want to make this change this way. Will explain an alternative approach in a comment.

[matthewp]

Basically we need to know that we are "inside of a template" in order to maybe not emit the script. I think that's really only possible through a compiler change.

If you have that, you would know when you've exited all possible templates and then could emit the script. cc @Princesseuh

[seroperson]

@matthewp Thank you for the review! Oh, I wasn't aware about such ability at all. Yea, compiler-based approach looks much better.

I filled the PR to compiler and did necessary changes here to support it. Well, then waiting compiler to be merged and then I'll update the version here.

P.S. I actually "moved" this render instruction to be inlined by compiler, so logic within this PR left mostly unchanged (except placing instructions of course).