Add declarative per-group workspace setup for Hermes Marmot

[Datawav]

Summary

The Hermes Marmot installer persists transport/account/display settings, but it cannot declaratively configure Marmot groups as durable Hermes workspaces. Operators who use one agent across several groups must hand-edit config.yaml to add per-group channel_overrides/legacy channel_prompts, optional profile_routes, and a verified default channel.

This is distinct from #1228 (show the Marmot group subject in chat metadata), #1224 (phone pairing and verified first conversation/home-channel selection), and #1231 (diagnostics). It is about idempotent configuration of group-scoped agent behavior after groups exist.

Verified against MDK 3c665c1b846139ad602185c463062b579bb48fd0 after searching open and closed issues.

Current behavior

• prepare_gateway_config() persists only Marmot activation, home/socket/account, welcomer policy, profile-name onboarding, and display/streaming settings.
• The CLI surface has no group/workspace inputs; it moves directly from account/welcomer options to display options: build_parser().
• Inbound routing already uses the immutable full group ID and chat_type="group", which is the correct stable key: adapter.py.
• Environment-only enablement can seed one home_channel, but only as an ephemeral process-environment bridge; the config helper does not persist or validate it: _env_enablement().

Hermes already has native config seams for per-channel system prompt/model/provider overrides and top-level profile routing. A successful multi-group installation therefore works today, but requires bespoke YAML editing that fresh installs cannot reproduce safely or idempotently.

Proposed design

Add an MDK-owned declarative input to hermes_marmot_configure_gateway.py and the release installer, suitable for both guided setup and automation. A versioned YAML/JSON file is preferable to embedding long prompts in shell arguments, for example:

version: 1
groups:
  - group_id_hex: "<64 lowercase hex>"
    system_prompt_file: "/path/to/project-scope.md"
    profile: "project-profile"        # optional
    home: false                       # at most one true

The configurator should resolve each group through the selected wn-agent account before mutation, show a privacy-safe subject/fingerprint confirmation, then merge only Marmot-owned entries into Hermes' native platforms.marmot.channel_overrides, profile_routes, and home_channel structures. Provide a dry-run that displays the planned structural changes without prompt contents or full identifiers.

Do not automatically enable global group_sessions_per_user; instead, detect and explain its effective session-isolation behavior, because changing a global session policy can affect unrelated platforms. Immutable full group IDs must remain the route/session keys; mutable subjects are display/confirmation metadata only.

Security and privacy boundaries

• Treat prompt files and existing YAML as untrusted operator input, never as executable shell fragments.
• Canonicalize and validate prompt paths; bound file size and reject non-regular files/symlinks unless an explicit safe policy is defined.
• Never print prompt bodies, full group IDs, account IDs, tokens, or private group subjects in default logs/dry-run output.
• Require explicit confirmation before replacing an existing prompt/profile route or choosing a home channel; unrelated platforms and routes must remain byte-for-byte/semantically unchanged.
• Configuration scope does not grant the agent authority to publish, contact third parties, deploy, or perform destructive actions; generated examples should say this explicitly.

Acceptance criteria

• Guided setup can select one or more groups and attach a durable workspace description/system prompt to each.
• Noninteractive setup accepts a versioned declarative file and is idempotent.
• Optional profile routing and at-most-one home channel use the immutable full Marmot group ID and Hermes-native config structures.
• Every configured group is syntax-checked and resolved against the selected account before any write; all validation completes before the existing atomic config transaction begins.
• Re-running merges Marmot-owned entries without deleting unrelated platforms, channel overrides, profile routes, or manually managed fields.
• Removal/reconciliation semantics are explicit: absence does not delete; deletion requires a separate explicit flag or manifest mode.
• Dry-run and normal output redact prompt text, full identifiers, subjects, sensitive paths, and credentials by default.
• Global session-isolation settings are detected/documented but never silently changed.
• Tests cover multiple groups, same subject/different IDs, renamed subjects, unknown group, malformed/duplicate IDs, missing/oversized/symlinked prompt files, route conflicts, one-home constraint, dry-run, idempotent re-run, explicit removal, rollback on validation/write failure, and preservation of unrelated config.

Related issues rejected as duplicates for narrower concerns

• Hermes ignores Marmot group subjects in chat metadata #1228: human-readable group subject in Hermes chat metadata.
• Complete Hermes Marmot onboarding with phone pairing and a verified first conversation #1224: pairing, authorization, verified first conversation, and home-channel selection.
• Add a privacy-safe diagnostic surface for Hermes Marmot installations #1231: privacy-safe diagnostics and home-channel health.
• install-hermes-marmot.sh: fresh install leaves the Marmot platform disabled in the Hermes gateway #838 and fix(hermes): make installed Marmot config satisfy gateway readiness without duplicate service environment #1127: fresh-install platform activation/readiness from persisted config (completed).