Deprecate some `astro:transitions` API

[ArmandPhilippot]

Description

I was updating the astro:transitions reference in docs (withastro/docs#12734) to add some undocumented APIs. Based on @martrapp feedbacks there, we might want to deprecate some APIs:

• createAnimationScope()
• isTransitionBeforePreparationEvent()
• isTransitionBeforeSwapEvent()
• TRANSITION_BEFORE_PREPARATION
• TRANSITION_AFTER_PREPARATION
• TRANSITION_BEFORE_SWAP
• TRANSITION_AFTER_SWAP
• TRANSITION_PAGE_LOAD

This seems reasonable to me. But, I'm not the framework expert here so let me know if there is any reasons not to do that. (ie., so far, I was thinking documenting everything (because some are used) except createAnimationScope()... if we don't want to deprecate createAnimationScope(), I need to know for docs)

I also noted that:

• ClientRouterModule, TransitionModule from astro:transitions are importable while those are internal types
• EventModule, TransitionRouterModule, TransitionSwapFunctionModule from astro:transitions/client are importable while those are internal types

Not a big deal, but maybe we want to prevent that with a clean up similar to the one Florian has suggested for astro:actions in #14608 (comment)

[martrapp]

Hi @ArmandPhilippot thank you for starting this!

Hi @matthewp, I guess it is in your interest as well that we cut the old ties and clean things up as described above. We can add to the deprecation message that these parts will be removed in Astro 7 since Astro 6 is probably coming a bit too soon for that. If that sounds right to you, give us a thumbs up so we can move ahead.

[martrapp]

Until when do we need to deprecate features so that the deprecation comes with Astro 6.0 and removal is possible from 7.0?

[florian-lefebvre]

We plan to release v6 early 2026 so there's still time. I can handle it if needed as long as the list is well defined!