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.