Issue

mempalace --palace <dir> init … silently ignores the --palace flag.
Init always creates the palace at the default ~/.mempalace/palace/
location and writes ~/.mempalace/config.json with the default path
baked in. There is no error, warning, or stderr line indicating the
flag was not honored.

The --palace flag is documented as a top-level argument
(mempalace --palace PALACE …) and is honored by mine, search, and
status — but not by init. The result is a confusing first-run
experience where users believe they have set up an isolated/test
palace at a custom location but the default is used instead.

Steps to reproduce

mempalace --palace ~/.mempalace-test init --yes --no-llm /tmp/some-project

ls ~/.mempalace-test
# → ls: cannot access '~/.mempalace-test': No such file or directory

ls ~/.mempalace/
# → config.json  known_entities.json  palace/

cat ~/.mempalace/config.json | head -3
# → "palace_path": "/Users/<you>/.mempalace/palace"
#   (the default, not the requested ~/.mempalace-test)

Expected

One of three behaviors, in rough order of preference:

1. Honor the flag. init should create the palace at the location
   passed via --palace, and write palace_path accordingly in the
   global config. This matches user expectations from the help output.
2. Fail-fast with a clear error. If init genuinely cannot use a
   non-default palace path (for architectural reasons), exit non-zero
   with a message like:

   error: --palace is not supported by `init`. Set palace_path in
   ~/.mempalace/config.json before running init, or run init at the
   default location and override --palace for subsequent commands.
   

3. Document the limitation. At minimum, the help text for init
   should explicitly note that --palace is ignored and reference the
   above workaround.

Why this matters

The intended user pattern when evaluating MemPalace is to set up an
isolated test palace ("sandbox first, commit later"). Today, that's
not possible without manually pre-editing the global config — which
isn't documented anywhere a user evaluating the tool would see. Users
who try the obvious --palace flag get a default-location palace and
no indication anything was unusual, and only discover the issue after
attempting to inspect the (non-existent) test path.

Environment

• mempalace 3.3.4 (latest as of 2026-05-02)
• macOS 25.3.0 (Darwin), Python 3.11
• Installed via uv tool install mempalace==3.3.4

Related context

• Issue mempalace init writes entities.json and mempalace.yaml to project directory instead of ~/.mempalace/ #185 covers a related concern about init writing
  mempalace.yaml and entities.json into the project root rather
  than the palace dir; PR feat: support .mempalace/ subdirectory for project config #933 is open against it. The two issues are
  adjacent (both about init's surface area) but distinct.
• Encountered while running an evaluation test plan against a
  multi-worktree project with the goal of mining six conversation
  wings into a single palace. Full surprises log (which prompted this
  issue) is at the user's .claude/MEMPALACE_TEST.md and could be
  shared on request.

Suggested patch shape

lib/commands/init.py (or equivalent) should read the --palace
arg from sys.argv (or however the top-level option is plumbed),
default to ~/.mempalace/palace if unset, and use the resolved
value as the palace_path written to the global config. If the
top-level --palace is intentionally meant to be a per-call
override only and not influence config, that intent should be
documented and an init-specific --palace-dir flag added.