Add end-agency enrichment and the channel/pricing confidentiality rule

Bryan, two related requests:

1. When a topic has a real end-client agency, the skill should resolve
   its full identity -- not just whatever name got said in the meeting.
   Added as a new standing step: check the MPM Technical Reference
   System first (agency-roster.md, clients-and-partners.md -- cheap,
   already-vetted), fall back to public web research, resolve BOTH the
   legal entity name and the separate transit brand name distinctly
   (validated pattern, confirmed against MPM's own FTA filings for
   Oshkosh: 'City of Oshkosh, Wisconsin, dba: GO Transit'), re-host the
   logo as a data URI rather than hotlinking it, and capture general
   agency contact info. Gets its own 'End Agency' card, separate from
   individual attendees.

2. Pricing shown in the Oshkosh brief was correct for an internal
   audience, but Bryan flagged that an external-facing version must
   never show the end agency MPM's price to the reseller -- they aren't
   privy to it. Documented as a new Hard Rule, grounded directly in the
   Technical Reference System's own reseller-channel.md (MPM's contract
   of record is with the reseller, not the agency, on channel accounts)
   rather than invented from scratch. Doesn't change internal-meeting-
   brief's current behavior (it's internal by definition) -- recorded
   here as the binding rule for vendor-partner-brief and kickoff-brief's
   external-client variant, neither built yet.

skills/internal-meeting-brief/SKILL.md

@@ -178,6 +178,31 @@ fixed list per brief type:
   here, or flag it `open` if the registry doesn't resolve it (e.g. a variant with no
   assigned code yet). This registry is a genuine dependency, not this skill's own
   content to maintain — see Dependencies.
+- **End agency / client organization — identify and enrich it, not just the people.**
+  When a topic has a real end client (a transit agency, most commonly), resolve its
+  full identity, not just whatever name got said in the meeting:
+  1. Check the MPM Technical Reference System first — `60-proof/agency-roster.md`
+     (is this agency already a known MPM deployment? gives HQ city/state) and
+     `60-proof/clients-and-partners.md`. Cheap, already-vetted, check before the web.
+  2. If not found or incomplete, search the public web for the agency's official
+     site. Resolve **both** names, distinctly — most transit agencies have a legal/
+     governmental name and a separate public transit brand, and both matter for
+     different reasons (contracts use the legal name; everything rider-facing uses
+     the brand). The precise, correct pattern — confirmed against MPM's own FTA
+     filings for Oshkosh — is **"[Legal Entity], dba: [Transit Brand]"** (e.g. "City
+     of Oshkosh, Wisconsin, dba: GO Transit"). Don't collapse these into one name or
+     guess which is which.
+  3. Pull the agency's logo and re-host it as a data URI embedded in the brief — do
+     not hotlink to an external image URL. This is the same "own content at
+     creation" principle already applied to fonts/tokens elsewhere in Brief: the
+     brief must survive as a standalone file even if the agency's website changes.
+  4. Capture the agency's general contact info (main line, address) alongside — not
+     a replacement for a named individual contact (see attendee resolution above),
+     supporting information for anyone reading the brief who needs to look the
+     agency up independently.
+  Present this as its own clearly-labeled card/section (see
+  `references/section-structure.md`), separate from the internal attendee list —
+  this is organizational identity, not a meeting participant.
 
 Helpdesk ticket review is still a deliberate, manual exception (see below) — not
 pulled automatically regardless of topic type.
@@ -268,6 +293,20 @@ person needs to actually see and review it, not just trust it happened.
   correct; a brief with invented content to fill them is not.
 - **Bounded queries only.** Gmail/Chat scans are scoped by project keyword + date
   window from the manifest. Never an open-ended search.
+- **Channel/pricing confidentiality by audience.** internal-meeting-brief is internal
+  by definition, so this doesn't block anything it currently does — but it's the rule
+  that must govern any future external-facing brief type (vendor-partner-brief,
+  kickoff-brief's external-client variant), so it's recorded here where the pattern
+  first came up. Grounded in MPM's own Technical Reference System
+  (`60-proof/reseller-channel.md`): on a reseller-sold account, **MPM's contract of
+  record is with the reseller, not the end agency** — the agency is not privy to
+  what MPM charged the reseller, only to whatever the reseller separately agreed
+  with them. A brief ever shown to the end agency must exclude MPM's own SO/PO
+  pricing entirely on a channel account, not just redact the total — line-item
+  pricing implies the same thing. This is not "hide pricing from external
+  audiences" generically: a *direct* account (no reseller) showing an agency its own
+  figures is normal. The dividing line is whether there's a reseller between MPM and
+  the reader, not whether the reader is external to MPM.
 - **No live publishing yet.** This skill produces a local file only. Hosting/publishing
   (a shareable link, external access control) is CW-029 (Brief Server) — deliberately
   separate, deliberately not built yet. Don't attempt to stand up delivery

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

@@ -18,6 +18,11 @@ structure per meeting. This is the contract — read it before generating a brie
    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.
+   **If the topic has a real end-client organization** (an agency, most commonly),
+   give it a distinct "End Agency" card of its own — separate from individual
+   people — showing the legal-name/brand-name pair (e.g. "City of Oshkosh, dba: GO
+   Transit"), a re-hosted logo, website, and general contact info. See SKILL.md
+   step 5.
 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