METPO proposal: intra-proposal pattern-key clashes are unguarded

Found reviewing #751. Low severity, latent. `validate_against_metpo` checks each proposed label/synonym against *existing* METPO, but nothing checks proposed terms against **each other**. `_build_metpo_lookups` keys `metpo_pattern_to_predicate` on every synonym plus the label, and writes last-wins: ```python self.metpo_pattern_to_predicate[pattern_key]["positive"] = curie ``` So two proposed properties of the same polarity sharing a synonym silently collapse: one predicate wins the key, the other becomes unreachable through that pattern, with no warning at generation or load time. There is no clash today (verified across all 9 property rows). The reason to file it now is that #751 makes property synonyms actually reach the submittable artifact for the first time, so the surface exists where it previously did not — every property synonym is now a live pattern key. ### Ask In `validate_against_metpo` (or alongside it), fail when two proposed terms of the same polarity normalise to the same key. Cheap to fold into the pairing test proposed in the sibling issue.