docs(odf): plan the drawing work #771 asks for, in the order the corpus argues for

[andiwand]

🤖 Generated with Claude Code

First of a six-PR stack closing #771. Docs only: src/odr/internal/odf/PLAN.md,
plus the links to it from the root AGENTS.md and odf/AGENTS.md.

#771 lists four sub-topics and nine unparsed shape tags. This writes down which
of them are worth building, in what order, and what the test corpus says about
each — the same shape as iwork/PLAN.md and rtf/PLAN.md.

What the corpus argued for

Occurrences over the 124 ODF files in test/data/input, counted across every
.xml part:

markup	occurrences	files
draw:enhanced-geometry	350	10
draw:object	1122	21
draw:transform=	25	4
draw:measure	27	1
draw:path	6	4
draw:polygon, draw:polyline, draw:caption, draw:regular-polygon, dr3d:scene	0	0

Five of the nine unparsed tags occur nowhere, and draw:enhanced-geometry is
by far the most common — which is what puts the enhanced path ahead of the
shape list, and what argues against inventing an ElementType per tag.

The two decisions every later stage depends on

• No new ElementType. custom_shape becomes the general "geometry given
  rather than named" type, the way draw:g already collapses onto frame.
  Adding one type costs 14 files across four binding layers.
• A transform is an element accessor, not a GraphicStyle field.
  get_intermediate_style overrides down the element parent chain, so a style
  field would leak a group's transform onto every child.

The stack

1. draw:transform — this PR's successor
2. the missing shape elements
3. draw:enhanced-path and draw:equation, parser only
4. enhanced geometry, rendered — closes support odf custom-shape #159
5. draw:object charts — closes ods chart missing #179

No consumer-visible change, so no CHANGELOG.md entry.