feat(engagement): the admin ceiling and core's news.post emitter (Phase 11a)

Core's half of ENGAGEMENT.md Phase 11a: the two decisions the org lead settled
before any code that land in core rather than in module-uo. Pairs with
Module-uo#22 and docs#194.

## Decision 1 -- a seventh ceiling, `admin`, as a child of `staff`

Phase 11's operator-facing triggers (uo.audit.staff_action, uo.economy.milestone,
uo.world.saved) are described as admin-audience everywhere, and the narrowest
value the lattice had was `staff` -- which ceilings.js defines as admin, editor
AND moderator. Ceilinging them there would have let an operator save a rule that
mails the staff audit digest to every moderator in it.

`admin` is the ONLY genuine refinement in the tree -- every admin is staff, which
is exactly the containment every other pair of branches lacks -- so it is a child
rather than a seventh leaf, and permits/meet/meetAll needed no change beyond the
new PARENT entry.

**The one non-obvious consequence, and the reason for ROLE_CEILINGS.**
notificationChannelPrefs' `visibleTo` asked `item.ceiling !== 'staff'`. That was
correct while `staff` was the only role-gated value, and the day `admin` arrived
it would have silently published every admin-ceilinged id -- the staff audit
digest, the economy thresholds -- to every player's preferences screen by name.
It now reads a TABLE (`ceilings.reachableBy`), so a ceiling added without an entry
fails closed instead. An EDITOR is the viewer that tells the two rules apart, and
the new tests use one.

MODULE_API_VERSION -> 1.8.0 on both halves. Additive: every declaration valid
under 1.7.0 is valid now and no stored value changes.

## Decision 5 -- 7.1 Q9: news.post gets an emitter, and it REPLACES the tickle

`news.post` has been a declared payload contract with no caller since Phase 2, so
a rule naming it could never fire. utils/newsNotify.js is the caller;
announceIfNewlyPublished now calls it instead of pushDispatch.publish, gated on
the same enqueueIfNeeded job id -- the single "newly published news" transition
signal, not re-derived.

**News push therefore stops on upgrade** until an operator enables the seeded
rule. That is the org lead's decision, taken over keeping the raw call beside the
emit "for one release": an exception with a deadline nobody owns, which Phase 6
already refused for Teams. The Rules screen gains a second migration notice
naming news, and Phase 13's release note carries it as an upgrade step.

**The seed needed its own one-shot key, and this is the trap worth recording.**
`engagement_team_rules_seeded` is already stamped on every deployment that has
booted since Phase 6, and the guard reads its presence -- so appending news to
RULES would have seeded it on fresh installs only, and on exactly the upgrades
that lose their raw push, never. One key per seed GROUP is now the rule;
seedGroup() is the shared implementation and seedCoreRules() is what boot calls.

Also fixes news.post's `postUrl` example, which named `/news/<slug>` -- a path
App.jsx does not mount. An example is what the template editor previews and
test-sends with, so a wrong one is a preview that looks right and a mail that is
not. It is `/site/news`, the list, which is what the Discord and town-crier
announcements have always linked.

1550 tests pass (16 new), 327 client tests pass, client builds, check:modules
clean -- core still names no module identifier with module-uo now registering 24
UO-named triggers.

Co-Authored-By: Claude <noreply@anthropic.com>

client/src/routes/admin/views/EngagementRules.jsx

@@ -494,6 +494,15 @@ function RuleEditor({ catalog, segments, rule, onSaved, onCancel }) {
 // It reads the RULES rather than a flag, so it disappears the moment one is
 // switched on and comes back if every one is switched off again. A deployment
 // that deleted them all sees nothing, which is right: they made that choice.
+//
+// **Phase 11 added a second notice of exactly the same shape, for news**
+// (ENGAGEMENT.md §7.1 Q9). Publishing a news post used to tickle every subscriber
+// directly, and that call is now an emit through the engine, so news push stops
+// on upgrade until the seeded `news.post` rule is switched on. Two notices rather
+// than one generalised "some rules are off" banner, deliberately: each names a
+// capability that USED to work without configuration and now does not, which is
+// a different statement from "you have a disabled rule" — and a rule an operator
+// created and disabled themselves must never produce a warning.
 const TEAM_TRIGGERS = [
   'team.forum.post',
   'team.announcement',
@@ -501,11 +510,32 @@ const TEAM_TRIGGERS = [
   'team.leadership.changed',
 ]
 
-function teamRulesAllOff(rules) {
-  const team = rules.filter((r) => TEAM_TRIGGERS.includes(r.triggerId || r.trigger_id))
-  return team.length > 0 && team.every((r) => !r.enabled)
+const NEWS_TRIGGERS = ['news.post']
+
+// One style for both notices, so the pair reads as one kind of message rather
+// than two that happen to look alike.
+const NOTICE_STYLE = {
+  fontSize: '0.85rem',
+  borderRadius: 8,
+  padding: '10px 12px',
+  marginBottom: 16,
+  border: '1px solid #7a6440',
+  color: '#e0b070',
 }
 
+const triggerOf = (rule) => rule.triggerId || rule.trigger_id
+
+// True only when rules for these triggers EXIST and every one of them is off.
+// Zero matching rules means the operator deleted them, which is a choice, not a
+// regression to warn about.
+function allOff(rules, triggers) {
+  const group = rules.filter((r) => triggers.includes(triggerOf(r)))
+  return group.length > 0 && group.every((r) => !r.enabled)
+}
+
+const teamRulesAllOff = (rules) => allOff(rules, TEAM_TRIGGERS)
+const newsRulesAllOff = (rules) => allOff(rules, NEWS_TRIGGERS)
+
 export default function EngagementRules() {
   const [catalog, setCatalog] = useState(null)
   const [segments, setSegments] = useState([])
@@ -583,13 +613,7 @@ export default function EngagementRules() {
   return (
     <section>
       {teamRulesAllOff(rules) && (
-        <div
-          className="sans"
-          style={{
-            fontSize: '0.85rem', borderRadius: 8, padding: '10px 12px', marginBottom: 16,
-            border: '1px solid #7a6440', color: '#e0b070',
-          }}
-        >
+        <div className="sans" style={NOTICE_STYLE}>
           <strong>Team notification emails are off.</strong> They used to be sent automatically; they
           are now rules, and the four below arrived switched off so that nothing starts mailing on its
           own. Switch on the ones this deployment wants — per-member preferences and per-Team mutes
@@ -597,6 +621,16 @@ export default function EngagementRules() {
         </div>
       )}
 
+      {newsRulesAllOff(rules) && (
+        <div className="sans" style={NOTICE_STYLE}>
+          <strong>News notifications are off.</strong> Publishing a news post used to send a push
+          notification to everyone subscribed to it. That is now the “News posts” rule below, and it
+          arrived switched off for the same reason the Team rules did. Switch it on to resume news
+          push — it also carries email and the in-app inbox, each still subject to each person’s own
+          preferences. The in-game town crier and the Discord announcement are unaffected either way.
+        </div>
+      )}
+
       <div style={{ display: 'flex', justifyContent: 'space-between', alignItems: 'center', marginBottom: 16 }}>
         <p className="sans" style={{ margin: 0, fontSize: '0.86rem', color: 'var(--muted)', maxWidth: 640 }}>
           A rule turns an event into mail: which event, who hears about it, on which channels, and how

client/src/routes/admin/views/EngagementTriggers.jsx

@@ -24,6 +24,7 @@ const CEILING_NOTE = {
   members: 'only members of the thing it is about',
   subscribers: 'only people who opted in',
   staff: 'only staff',
+  admin: 'only administrators',
   authenticated: 'any signed-in account',
   everyone: 'anyone',
 }