Board/Calendar: primary field and groupBy can point at the same field, showing redundant controls

[brylie]

Problem

Board and Calendar's groupBy (the select/date property driving columns or day placement) and a Collection's primaryFieldKey (#96) are independent choices — nothing stops a user from picking the same field for both. When that happens, a card ends up with two separate controls editing the identical underlying value:

• The card's big title cell (PropertyValueCell for the primary field, rendered directly editable per collection-views.md §7).
• Board's "Move to column" <select> / Calendar's date picker (the existing groupBy-driven control).

Neither is broken — both write to the same property key and stay in sync — but it reads as a redundant, slightly confusing pair of controls for one value, discovered while implementing #96 but not exercised by its test suite or spec.

Scope

• Decide the UX: options include (a) leave as-is and document it as an accepted edge case, (b) when primaryFieldKey === groupBy, suppress the card's title PropertyValueCell in favor of a plain (non-editable) label so there's exactly one editable control for that value, or (c) something else — this needs a product decision, not just an implementation.
• Whatever is decided, add it to collection-views.md §7 so the behavior is documented rather than incidental.
• Add a test (Board and/or Calendar component test) covering the chosen behavior when primaryFieldKey and groupBy name the same field.

Non-goals

• Not preventing a user from choosing the same field for both — there's no correctness reason to forbid it, only a possible UX cleanup.

Done when

The behavior when primaryFieldKey === groupBy is a deliberate, documented, tested choice rather than an untested overlap of two independently-added features.

[brylie]

Set Priority: P2.

Cosmetic edge case (two controls editing one value when primaryFieldKey and groupBy coincide) — not broken, low likelihood, and needs a product UX decision before any code change.