Panic on valid CDDL: bare value in a group choice unwraps None in count_group_choice_items

[renz011tzar]

cddlconv panics on valid CDDL when a group choice contains a bare value.

Verified at 5609f26.

Reproduction

x = ( 1 // 2 )

$ cddlconv -f zod input.cddl
thread 'main' panicked at src/engines/zod.rs:1050:49:
called `Option::unwrap()` on a `None` value

Same input with -f type-script panics too. Minimal form: x=(1//2).

Cause

count_group_choice_items assumes every ValueMemberKey group entry has a member key:

// src/engines/zod.rs:1050
cddl::ast::GroupEntry::ValueMemberKey { ge, .. } => {
    let mk = ge.member_key.as_ref().unwrap();

A bare value in a group choice (1, 2 above) is a valid group entry with no
member key, so member_key is None and the unwrap() panics. This is legal
CDDL per RFC 8610 (a group entry's member key is optional).

Suggested fix

Handle the None case — a bare value counts as one item and needs no key, e.g.:

match &ge.member_key {
    Some(mk) => { /* existing per-key logic */ }
    None => { in_object = false; count += 1; }
}

Related — a second panic on valid input

A .eq control operator hits an unimplemented!() in the same engine:

y = tstr .eq "x"

thread 'main' panicked at src/engines/zod.rs:865:29

This one looks like a deliberately-unimplemented control operator rather than an
oversight, so I've noted it separately — but it does abort on valid input, and
the type-script engine handles the same construct, so the zod engine may just
need the corresponding arm.

How this was found

While evaluating Rust verification tooling: the midas-lex
workflow flagged the missing None case as the spec owner, and a small
Verus model confirmed that a keyless entry
is reachable and that handling it is total. Happy to send a PR for the :1050
fix.