[BUG] pptx: `set width` on a group silently scales height too (implicit aspect-ratio lock, no opt-out)

## Summary

`set` on a **group** silently locks the aspect ratio: setting only `width` also scales `height` (and vice versa). There is no way at L2 to resize a group along a single axis; the only workaround is `raw-set` on `p:grpSpPr/a:xfrm/a:ext`.

## Repro (v1.0.136)

```bash
officecli create g.pptx
officecli add g.pptx / --type slide
officecli add g.pptx '/slide[1]' --type shape --prop geometry=rect --prop x=2cm --prop y=2cm --prop width=4cm --prop height=2cm
officecli add g.pptx '/slide[1]' --type shape --prop geometry=rect --prop x=8cm --prop y=5cm --prop width=4cm --prop height=2cm
officecli add g.pptx '/slide[1]' --type group --prop shapes=1,2
officecli get g.pptx '/slide[1]/group[1]'
# -> x=2cm y=2cm width=10cm height=5cm

officecli set g.pptx '/slide[1]/group[1]' --prop x=1cm --prop width=12cm
officecli get g.pptx '/slide[1]/group[1]'
# -> width=12cm height=6cm <-- height changed from 5cm to 6cm, was never requested
```

## Expected

`set width` on a group should change only `ext.cx` (children scale horizontally via the chExt mapping), matching the behavior of `set width` on a plain shape. If the aspect lock is intentional, it should be opt-in (e.g. `--prop keepAspect=true`) and the default should honor exactly the properties the caller passed.

## Workaround for others hitting this

```bash
officecli raw-set deck.pptx ppt/slides/slideN.xml \
--xpath "//p:grpSp[...]/p:grpSpPr/a:xfrm/a:ext" \
--action setattr --xml 'cy='
```

Reproduce the issue with the officecli create/add/set/get sequence and compare group resizing with plain-shape resizing. Trace the group set handling around the p:grpSpPr/a:xfrm/a:ext and chExt mapping described in the report. Done means setting only width or height changes that axis, with the result verified through officecli get and no unintended aspect-ratio scaling.

Written by the indexing model from the issue text.