fix(user_data): support default=false in multi-select choice syntax

[BillionClaw]

Allow setting default=false in the extended choice syntax for multi-select questions. Previously, the default property in choice definitions was ignored.

With this change, users can specify:

choices:

• value: feature_a
  default: false
• value: feature_b
  default: true

The choice-level default is respected when no question-level default is set. When a question-level default list is provided, it overrides the choice-level defaults for backward compatibility.

Related to #2421

[sisp]

Thanks for suggesting this feature and submitting a PR, @BillionClaw! 👍

I'm not fully convinced yet by the approach TBH:

• It introduces ambiguity between the question-level and choice-level default fields. I think we'd need at least a warning when both are set. I understand how this solves the problem of ensuring a valid default value for dynamic choices (via rendered choices or conditionally disabled choice items), but it feels conceptually inconsistent to have two places for defining (part of) the default value. I was thinking about similar cases, and JSON Schema's default field/annotation came to my mind, but I think this is still different because it indicates an implicit value when an optional property is missing; here, we're declaring the default value unless selected/provided differently by a user, and the question-level default field contains an answer value while the choice-level default field is a flag indicating whether the choice value contributes to the default answer value.

• A similar problem remains for the question-level validator field, so this may be a solution for the default value problem but doesn't address these general challenges of complex dynamic choice questions.

I'm curious about your thoughts.

[bobo-xxx]

Just checking in — is this ready for review?

[onthebed]

I'll get the CLA signed — will follow up once it's done.

[onthebed]

Not quite yet — I still need to address the ambiguity between question-level and choice-level defaults. I’m going to update the PR to handle that cleanly before marking it ready for review.

[onthebed]

Thanks for the feedback. I don't see a narrower change that would resolve the ambiguity cleanly without broadening the default/validator model, so I'm going to leave this PR open rather than try to force a redesign into it.