refactor: establish ViewTransitions folder feature

[jderochervlk]

Tracking issue: #342

Stack context

Part 6 of the Option 5 folder-feature stack.

• Previous: refactor: establish Performance folder feature #315
• Next: another dependency-clean domain folder

Review this PR as the incremental diff against #315.

Summary

• rename src/ViewTransitions to the target src/view-transitions folder
• change the folder to the unqualified internal ViewTransitions feature
• add the supported WebAPI.ViewTransitions feature with its WebAPI.Event dependency
• preserve the flat public WebAPI.ViewTransition module

The internal ViewTransitionsTypes helper stays private inside the complete folder.

Temporary state

• this PR does not introduce compatibility aliases, file exclusions, or module slices; its folder and feature ownership are final
• helper-type colocation remains deferred to the final cleanup layer

Review focus

• the WebAPI.ViewTransitions -> WebAPI.Event + ViewTransitions implication
• unchanged public module path and binding signatures
• complete folder ownership

Verification

• node_modules/.bin/rescript clean
• node_modules/.bin/rescript build --prod --features DOM,Event,ViewTransitions
• npm run build
• npm test
• npm run format:check
• git diff --check

[jderochervlk]

@codex

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 16b0709e9b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep the supported ViewTransitions feature buildable

When a consumer selects --features WebAPI.ViewTransitions, this new implication transitively activates WebAPI.Event and WebAPI.DOM, as specified by rescript build --help, but not the DOMPlatform source containing DOMStringMap. I checked this feature combination from a clean build: it now exits with src/DOM/DOMTree.res:982 reporting that DOMStringMap cannot be found, whereas the same selector compiled successfully before this commit. Thus the newly supported public feature cannot actually be selected on its own; its implication set must include every source needed by the activated DOM modules.

Useful? React with 👍 / 👎.