fix(modules): bump the CLIENT half of MODULE_API_VERSION to 1.9.0

The two halves version ONE contract and a test asserts they agree
(client/test/moduleRegistry.test.js). I bumped server/src/modules/version.js and
not client/src/modules/version.js, so client-build went red — the job runs the
client suite before it builds.

Nothing on the client half changed: a seed is server-side data and core's seeders
write it on the boot path. It bumps for the reason its own header gives — a
module declares one `coreApi` range against both halves, and a client claiming
1.8.0 while the server answers 1.9.0 is two answers to one question.

327 client tests green; client build clean.

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

client/src/modules/version.js

@@ -11,6 +11,13 @@
 // that the two files can drift, so a test asserts they agree
 // (client/test/moduleRegistry.test.js) rather than trusting a bump to remember
 // both.
+// 1.9.0 - a module may ship its own message bodies and rules:
+// `api.registerEngagementSeeds({ templates, ruleGroups })` (ENGAGEMENT.md Phase
+// 11b, decision 7). Nothing on this half changed - a seed is server-side data
+// and core's seeders write it on the boot path - but the bodies it ships are
+// edited through the template editor this half already renders, and an operator
+// meets them there. This file bumps for the reason at the top: the two halves
+// state ONE version, and a module declares one `coreApi` range against both.
 // 1.8.0 - the ceiling lattice gains `admin` (ENGAGEMENT.md Phase 11). Nothing on
 // this half changed: a ceiling is declared on the server's `api` and enforced
 // there, and the admin screens that render one read the vocabulary from
@@ -58,4 +65,4 @@
 // but the two halves state ONE version: a module declares a single coreApi range
 // and is served one chunk, so a client that claimed 1.0.0 while the server
 // answered 1.1.0 would be two answers to one question.
-export const MODULE_API_VERSION = '1.8.0'
+export const MODULE_API_VERSION = '1.9.0'