fix(gateway): sync /model and /personality with CLI pattern

[VencentSoliman]

Issue

When a user runs /model on Discord (or any gateway platform), it
displays "anthropic/claude-opus-4.6" the hardcoded fallback (or nothing on accounts of other users) even
though the agent is actually using the model from config.yaml (e.g.
minimax-m2.5). Running /model reports success, but the next
message still uses whatever config.yaml says. Similarly, /personality
reports success but the personality never changes.

To reproduce:

1. Set model.default to any model in ~/.hermes/config.yaml
2. Start the gateway, run /model, shows the wrong model
3. Run /model some-other-model, send a message , old model still used
4. Run /personality pirate, send a message , no personality change

Fix

Align gateway /model and /personality command handlers with how
the CLI chat (hermes chat) already handles them. reading from and
writing to config.yaml instead of environment variables.

builds on the patterns established by @teknium1 in:

• bc76a03 - where save_config_value and the CLI /model +
  /personality handlers were introduced with config.yaml as
  the source of truth
• 55a0178 where the gateway's agent init was updated to re-read
  config.yaml per message.

The gateway command handlers were the last piece that hadn't caught
up to this pattern as they still wrote to env vars that the agent init
immediately overrides from config.yaml.

Changes

Not trying to intro new pattern/style, uses the same yaml read-modify-write
approach already present in the gateway's _handle_set_home_command.

• /model display now resolves from config.yaml using the same chain
  as the agent init, instead of the HERMES_MODEL env var fallback
• /model <name> persists to model.default in config.yaml (matching
  CLI's save_config_value("model.default", ...) at cli.py:1656)
• /personality <name> writes to agent.system_prompt in config.yaml
  and updates the in-memory ephemeral prompt (matching CLI's
  save_config_value("agent.system_prompt", ...) at cli.py:1386)
• Removes the orphaned HERMES_PERSONALITY env var write (zero
  consumers in the codebase)

Test plan

• Make sure error is actually reproducible across different users
• /model (no args) → should show model from config.yaml
• /model other-model → /model again → should show other-model
• Send a message → verify new model is used
• /personality pirate → /new → send a message → pirate-style response
• Check ~/.hermes/config.yaml after each → values persisted

Tested on: Linux (WSL2), Discord

[VencentSoliman]

Rebased on main to stay current with the latest changes.

Saw the model display resolution in e09ef6b that config.yaml fallback is the right call. This PR picks up where that left off and covers the two remaining pieces:

Table 👇

Command	Behavior on main	What this PR adds
/model (no args)	Reads config.yaml when env is empty ✅ (e09ef6b)	already fixed
/model provider/name	Writes to env var → overridden by config.yaml on next message ❌	Writes to config.yaml so the change persists ✅
/personality <name>	Writes to HERMES_PERSONALITY env var → nothing reads it ❌	Writes to agent.system_prompt in config.yaml + updates in-memory prompt ✅

/model write side: The display is fixed, but /model provider/name still only sets os.environ["HERMES_MODEL"]. The agent init re-reads config.yaml on every message and overrides the env var, so the change silently reverts. This adds a config.yaml write using the same yaml read-modify-write pattern from the CLI's save_config_value.

/personality config persistence: Currently writes to os.environ["HERMES_PERSONALITY"], which nothing in the codebase reads. The CLI equivalent writes to agent.system_prompt in config.yaml and updates the in-memory prompt. This mirrors that exactly.

just bringing the gateway commands in line with how the CLI already handles these operations.

Do not merge if the intention for the /model command on gateways was for it to be a temp session-level override! 🙅‍♂️

[teknium1]

Thanks!