changelog: #6498 gate memory/user-profile reads via nested config (re-gate)

CHANGELOG.md

@@ -21,6 +21,8 @@
 
 ### Fixed
 
+- **The memory panel now honors `memory_enabled` and `user_profile_enabled`.** The Settings → Memory read/write endpoints previously loaded and saved `MEMORY.md` / `USER.md` regardless of those config flags, so a profile that disabled memory or the user profile still exposed and mutated the files. Both endpoints now read the flags from the per-profile config snapshot (`config.memory.memory_enabled` / `config.memory.user_profile_enabled`): a disabled section is omitted from reads and rejected with a 403 on write, while the default-on behavior is preserved when the flags are absent. Thanks @webtecnica. (#6498, #6406)
+
 - **When a turn hits the tool-call limit, its final written answer now renders alongside the limit status card instead of being replaced by it.** In the ordinary (non-transparent) transcript branch, the presence of the tool-limit status card was counted as the turn's "visible body," so a genuine final assistant report was suppressed and the user saw only the status card (whose own subtitle promises "the written answer below"). The status card no longer counts as the visible body, so a non-empty report renders together with the card and picks up the standard message footer/actions; status-only turns (no report) still show just the card, and card ordering is unchanged. Thanks @rodboev. (#6486, #6467)
 
 - **A mid-run reload no longer briefly shows the active turn's prompt twice.** While a turn is live the server can reconcile the current user row into the returned transcript (via the state.db merge) while `pending_user_message` is still set, and that row is then followed by the same turn's assistant/tool output — so the strict tail scan reported "no current user row" and the client materialized the pending prompt a second time, showing a duplicate user bubble until the settle render. The client now also matches the active turn's row by exact identity — the server-stamped `_active_turn_token` (`stream_id:started_at`) or a timestamp equal to `pending_started_at` within a precision-only epsilon — and adopts it instead of re-rendering. Matching is identity-only, never proximity: a rapid same-text repeat (e.g. sending "continue" twice ~1s apart) is treated as ambiguous and still materializes as its own turn, so a legitimate repeated prompt is never swallowed. Thanks @happy5318. (#6670)