v2.4.1 The editor's beneficiary shares, built and announced from one place (MR !176). - The editor announced beneficiary shares with arithmetic that disagreed with what it went on to broadcast: the dialog counted the form rows while the operation was assembled separately, so the two could drift. Across the configurations the validator accepts, the announced total was wrong in about one in five, and some announcements added up to more than 100%, which the chain cannot represent. The summary and the operation now come from a single buildBeneficiaries(), so what the author is shown is the list that is sent. - Automatic shares stay fixed. The community's and the referrer's 3% are never reduced, trimmed, or edited away. What the author adds is added on top, and when the total will not fit it is the author's own shares that yield, largest first. An account earning several shares becomes one entry with their sum, which is what the chain requires: it rejects a beneficiary listed twice. The convention is client-side and so unenforceable in the browser; the editor at least no longer offers the reduction itself. - The summary names each share's origin -- community, referrer, or set by the author -- on its own line, in place of the aggregate counter. The count corrected by !169 can no longer go wrong because nothing is counted any more: every share is listed with the amount it actually contributes. - validateBeneficiaries() now measures the author's shares against what is left, taking both the automatic percentages and the slots they occupy out of the budget, so validation and construction agree rather than each guessing. It also tolerates lists that reached it without passing through the form, which a hand-edited page can produce. - Applying a loaded template writes to the editor's store, not only to the dialog, so a template's beneficiaries survive being loaded.