Fix print CSS bug and fold in real-world findings from the first live invocation

First test run (Oshkosh GO Transit internal kickoff, via the actual
installed skill, not Claude manually walking the SKILL.md) surfaced real,
fixable gaps. All fixed here:

1. Print CSS bug (root cause, found by Bryan): section{break-inside:
   avoid-page} plus whole-table break-inside:avoid caused a 14-page,
   mostly-blank PDF. Fixed: sections can split across pages now; only
   cards/table-rows avoid splitting, with repeating table headers.

2. SO/PO lookup was wrongly scoped out of this brief type by default.
   Wrong -- an internal kickoff about a real sale needs the SO/PO as much
   as any external brief would. Scope is now by topic nature (commercial
   vs. purely internal), not by brief-type name.

3. Contact-info lookup (not just name resolution) is now an explicit
   standing step in attendee capture, starting from a linked SO/PO's own
   Odoo contacts when one exists.

4. Added the MPM Technical Reference System (a 131-file Drive registry:
   brand, platform, display tech, products, engineering, concepts, proof)
   as a standing reference for part-number/product verification --
   previously unknown to this skill.

5. Pulled the real run's improved _topic-state.md schema back into the
   spec: confidence tags (verified/stated/open), a folder-layout header,
   numbered-vs-proposed open items, a Findings/flags section. These
   emerged from real use and are now documented, not one-off.

6. Meeting transcript archival (a Meeting Transcripts/ subfolder) is now
   a standing step, not something that has to be asked for.

7. section-structure.md: flow and specbar are now marked validated (real
   examples: Oshkosh deployment sequence, billing milestones). Added the
   meeting-vs-proposed open-items badge pattern and a standard
   confidentiality footer note for this brief type.

None of this was a failure of judgment in the moment -- these are gaps
between what the file said and what real use needed, now closed.

skills/internal-meeting-brief/references/section-structure.md

@@ -8,10 +8,16 @@ structure per meeting. This is the contract — read it before generating a brie
 
 1. **Header** — title (meeting subject, not the raw Plaud filename), meeting date +
    duration, prepared date, source (transcript / manual notes), mode (Agenda/Recap).
+   Also attach relevant deal-identifying context in the header/subhead when the topic
+   is a commercial engagement — e.g. the SO/PO numbers and total, as validated in the
+   Oshkosh brief — so the document is self-identifying without opening the manifest.
 2. **Attendees** — one card per attendee. Internal MPM people resolved by name where
    possible. If Plaud's speaker diarization didn't resolve a name, render the literal
    transcript label ("Speaker 1," "Speaker 3") — never guess a name. Follow with a
    `note.info` flagging any unresolved speakers explicitly, so it's visible, not buried.
+   When external counterparts are named in discussion but weren't present, give them
+   their own card group ("Named in discussion, not present") with resolved contact
+   info (see SKILL.md step 4) rather than omitting them or burying them in prose.
 3. **Topics Covered** — a `cards` grid, one card per distinct subject actually
    discussed. Card count and grid density (c2/c3/c4) follow the number of real topics —
    don't pad to hit a round number, don't force unrelated topics into one card to save
@@ -23,7 +29,13 @@ structure per meeting. This is the contract — read it before generating a brie
    parallelism.
 5. **Open Items** — an `actions` table with status pills. Every action item needs an
    owner field even if the honest value is "Unassigned" — never leave the column blank,
-   since a blank reads as "forgotten to track" rather than "no owner yet."
+   since a blank reads as "forgotten to track" rather than "no owner yet." **When the
+   brief includes action items Claude is suggesting rather than items the meeting
+   itself raised** (validated pattern from the Oshkosh brief), split them into two
+   visually distinct tables with a labeled subhead and a badge (e.g. `MEETING` vs.
+   `PROPOSED`), and say explicitly that proposed items are suggestions needing an
+   owner to accept them — never blend a suggestion into the same table as a committed
+   action item where they'd read as equally real.
 6. **Notes & Flags** — one `note` per genuinely separate concern: data-source
    limitations encountered (a failed pull, a missing transcript), naming/identity
    uncertainty, anything that needed a judgment call worth surfacing rather than
@@ -37,13 +49,11 @@ sections above would flatten into an unreadable wall of text or an over-long tab
 Add one only when the meeting's actual content has this shape — never as decoration,
 never because a template "should" have variety.
 
-| If the content is... | Use... | Real example |
-|---|---|---|
-| A sequential, ordered process (3+ steps, each depending on the last) | `flow` | Anti-vandalism 3-tier escalation (09-16 meeting) |
+| If sequential, ordered process (3+ steps, each depending on the last) | `flow` | Anti-vandalism 3-tier escalation (09-16 meeting); Oshkosh deployment sequence, client kickoff → survey → mount → install → go-live → acceptance (09-22 meeting) — **validated in real production use** |
 | A named component/system with distinct sub-parts worth breaking out | `layerbox` + `filepill` | (not yet exercised on a real internal-meeting-brief; seen in development-brief-flavored source material) |
 | A genuine two-sided contrast (us/them, before/after, keep/avoid) | `compare` | (not yet exercised on internal-meeting-brief; used in vendor-partner-style source material) |
 | A spec/BOM-style matrix with yes/no or multi-column comparison | `unitgrid` | (not yet exercised) |
-| A handful of headline numbers worth calling out at a glance | `specbar` | (not yet exercised on internal-meeting-brief) |
+| A handful of headline numbers worth calling out at a glance | `specbar` | Oshkosh billing milestones — three estimate amounts + total, each with its own trigger condition — **validated in real production use** |
 
 **Rule of thumb:** if you're reaching for a dynamic section and can't point to the
 specific part of the meeting that has this shape, don't add it. The fixed six sections