apply_overwrites_to_context silently drops remaining overrides after first invalid entry

When default_context from the user config (e.g. ~/.cookiecutterrc or $COOKIECUTTER_CONFIG) contains a single override that fails type conversion, every subsequent override in the same default_context dict is silently discarded. The generated project ends up with a mix of user-set values and cookiecutter.json defaults, without any indication which overrides were lost.

Affected overrides

• Boolean variables: override that cannot be parsed by YesNoPrompt.
• Choice variables: override that is not in the declared list.
• Multichoice variables: override not a subset of the declared list.

Where to look

• cookiecutter/generate.py — apply_overwrites_to_context: the first invalid entry raises ValueError and exits the for variable, overwrite in overwrite_context.items() loop, so all remaining entries are never processed.
• cookiecutter/generate.py — generate_context: the ValueError is caught and downgraded to warnings.warn(f"Invalid default received: {error}"). The warning names only the failing variable, not the abandoned ones.

Impact

Silent, partial config merge. The warning is easy to miss in CI/Docker logs. Downstream templates produce incomplete output files and there is no way for a template author to detect this from a pre-gen hook — by then the context has already been partially merged.

Not affected

extra_context goes through the same function but without the surrounding try/except, so invalid overrides there raise hard. The silent path is default_context only.

Expected behavior

Per-entry isolation: collect errors, continue processing the remaining overrides, then report all offending entries together (either as a hard error or a single consolidated warning that lists every dropped variable).