odk-new-repeat event in model should always be rejected

[lognaturel]

Closes #830

I'm opening this for consideration and communication but I'm not convinced we should merge it. There are forms with dynamic defaults in repeats that were generated by pyxform that would stop working in Collect. That could be pretty disruptive. Users would have to reconvert with updated pyxform.

What has been done to verify that this works as intended?

Wrote and ran a new test.

Why is this the best possible solution? Were any other approaches considered?

This uses string comparison which would break if a new event that adds to odk-new-repeat were introduced. That's highly unlikely so I think it's the simplest solution. Otherwise we could split the space-separated string into a collection.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

It's going to break existing forms.

Do we need any specific form for testing your changes? If so, please attach one.

Any form with dynamic defaults in repeats or Entities from repeats.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

[lindsay-stevens]

I looked for history around odk-new-repeat and pyxform may have been doing the right thing for a while e.g. in v4.0.0 (2025-06-09) test_dynamic_default.py has XPath tests like test_dynamic_default_in_group_nested_in_repeat that check the setvalue element goes into the body/control for repeats. As an example this particular test first began specifically checking the setvalue location in XLSForm/pyxform#431 (which was to fix a bug putting it in the model XLSForm/pyxform#427) and 431 was included in v1.1.0 (2020-02-17) - shortly after the introduction of dynamic defaults in v1.0.0 (2020-02-06). Possibly exceptions and edge cases but it's some evidence a positive direction.