v1 to v2 project upgrade silently discards a view when two views.yml entries share the same name

[AmirF194]

Describe the bug

plan_upgrade/apply_upgrade (v1 to v2 project upgrade) silently discards a view when two entries in views.yml share the same name. _apply_v1_to_v2 resolves each view's target directory from name alone and writes both views into it, so the second write clobbers the first, and views.yml, the only other copy, is deleted right after. The upgrade exits 0 with one view's definition gone.

The same class of bug already has a guard for cubes (seen_cube_targets in _plan_v1_to_v2, added when duplicate cube files were found to collide the same way). Views never got the equivalent check.

To Reproduce

Given a v1 project with views.yml:

views:
  - name: summary
    statement: SELECT 'first' AS marker
  - name: summary
    statement: SELECT 'second' AS marker

Run the v1 to v2 upgrade (wren upgrade CLI, or plan_upgrade/apply_upgrade directly). It succeeds. views/summary/metadata.yml ends up containing only the second view's statement, and views.yml no longer exists, so the first view's definition is gone with no error or warning at any step.

Expected behavior

The upgrade should reject the project up front, the same way it already does for two legacy cube files that resolve to the same target (Cannot upgrade: multiple legacy cube files map to '...'), rather than silently dropping data.

Additional context

Traced this in core/wren/src/wren/context.py. Have a fix ready mirroring the existing cube guard, will open a PR referencing this issue.