refdata's generated wire projection is drifted and no gate covers it

Eighteen generated TypeScript files under projects/ores.web/packages/wire-protocol/src/generated/refdata/protocol/ do not match the output of the templates that produce them. Two kinds of difference:

• The render adds party_id to the write shape of every party-scoped entity. BookWrite gains it after id, and portfolio, business_unit, crm_driver_pair, party_contact_information and the rest follow. The generated C++ write struct does not carry it: book_protocol.hpp has no party_id anywhere, while domain/book.hpp has it and the TypeScript domain type honours it.
• The render drops the junction and entity *Event interfaces the tree still carries, such as CurrencyCalendarEvent and PartyCountryEvent.

The whole component is drifted, not only its TypeScript: rendering refdata at the default address reports 499 files that would change, C++ headers, repositories, services, shell commands and tests among them. That work is the clean-refdata story's, in flight on another branch.

Two things are wrong, and they are separate.

The projection is stale, because nothing regenerated it. refdata is not in COMPONENTS_UNDER_TEST, so the drift job does not render it; the sweep renders every catalogue component but fails only on files the branch touched. This capture exists because a formatting branch touched the files, and the sweep then reported them — which is the gate working exactly as designed.

And the two protocols disagree about party_id, which is a template defect rather than staleness. The TypeScript write shape carries a natural-key field the C++ write shape omits, so regenerating the TypeScript alone would make the browser send a field the server's parser never reads. Until that is settled, regenerating the TypeScript is not a safe fix.

• projects/ores.web/packages/wire-protocol/src/generated/refdata/protocol/book_protocol.ts — BookWrite, no party_id.
• projects/ores.refdata/api/include/ores.refdata.api/messaging/book_protocol.hpp — the C++ write struct, no party_id.
• projects/ores.refdata/api/include/ores.refdata.api/domain/book.hpp:74 and .../generated/refdata/domain/book.ts:38 — both domains carry it.
• projects/ores.refdata/modeling/ores.refdata.book.org — party_id is a natural-key field of the entity.
• check_component_drift.py --component refdata --dry-run — 499 files would change.
• projects/ores.web/.prettierignore — records the exclusion this put on the format check.

• The documented regenerate-all command generates components that do not project — found in the same pass.
• Format the generated TypeScript with prettier — the story that surfaced this.