fix(@angular/build): reject entry points that collide on bundle name

[thekhegay]

PR Checklist

• The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

• Bugfix

What is the current behavior?

Issue Number: #34128

getEntryPointBundleName flattens / to -, so ./zz/child and ./zz-child both produce lib-zz-child. The duplicate guard in normalizeEntryPoints keys on entryPoint.name, which still differs, so both survive. resolveEntryInputMap then writes input[bundleName] into a plain object and the second entry point silently overwrites the first, so Rolldown is handed one entry and cannot warn. The build exits 0, one entry point's code is missing, and both exports keys resolve to the surviving file.

What is the new behavior?

Normalization rejects the collision with an error naming both keys and the bundle name they share.

Two tests: a nested entry point beside a similarly named flat one still builds and emits both bundles, and the colliding pair fails. There was no test with a nested entry point before, so the / to - flattening itself was unpinned.

Does this PR introduce a breaking change?

• Yes
• No

Other information

I could not run the builder tests locally, so CI is the first run of them.

[gemini-code-assist]

Code Review

This pull request introduces a check to prevent entry point subpaths from producing colliding bundle names when '/' is flattened to '-', throwing an error if a collision is detected, and adds corresponding unit tests. The review feedback suggests making this collision check case-insensitive to ensure cross-platform safety on case-insensitive filesystems (such as macOS and Windows).

[alan-agius4]

Thanks for this, but this has been address via #34218