v0.2.2: Remote Memory Space Activation

v0.2.2 fixes Memory Space activation from a remote trusted DSH page and tightens the surrounding RPC authority boundaries.

#Fixed

• Activating or deactivating a Memory Space now uses the dedicated trusted-host /dsh-mnemon-activation control channel instead of the loopback-only general write channel.
• The activation handler accepts only a Memory Space ID, a Boolean active state, and normal session/workspace routing fields. Metadata, Provider configuration, credentials, deletion, and durable-memory writes cannot cross this boundary.
• The client falls back to the legacy write endpoint only when an older Host reports the new activation endpoint as missing. It does not retry a 403 or any business failure through a broader channel.
• Remote WebUI sessions keep activation available while disabling edit, delete, reconnect, memory distillation, document/runtime mutation, version update, settings, backups, and Provider configuration before transport.

#Authority audit

• The trusted-host Provider service catalog is now redacted and never returns saved credential values.
• Private Provider settings remain available to the local settings editor only through the loopback write channel.
• Message save actions, settings, backup import/export, Provider service controls, and version updates all apply the same loopback preflight rule.

#Compatibility and upgrading

Update dsh-mnemon and restart the affected DSH profile. On loopback connections, the browser client remains compatible with pre-v0.2.2 Hosts for activation and private Provider catalog reads through narrow missing-endpoint fallbacks; remote activation requires the updated Host boundary. This patch does not migrate, rewrite, or delete Runtime Memory, Project Documents, Memory Spaces, or Provider data.

See the v0.2.1 release notes for the previous patch release.