feat(installer): support clean installs and seed initial memories

- resolve current Hermes runtimes through PM and retain the legacy fallback
- exclude the unsupported Android sqlite-vec branch from universal resolution
- add idempotent explanation and installation-source memories
- add Docker clean-install and standalone seed regression tests
- document supported platforms and bump the plugin version to 1.3.0

feat(provider): add automatic recall via prefetch with per-session seen-set

- prefetch() embeds the current message plus a rolling topic (two prior
  user messages and the tail of the last reply, recorded by sync_turn)
  so short follow-ups retrieve on-topic memories; injects up to
  PREFETCH_LIMIT=30 memories per turn as a "Retinue recall (N fresh)"
  block
- per-session in-RAM seen-set filters ids already returned, shared with
  retinue_memory_search (new include_seen parameter, default false;
  limit default now 30); on_session_switch and on_pre_compress clear it
- warm the embedding model on a daemon thread at initialize() and guard
  get_model() with a lock so warmup and concurrent tool calls cannot
  double-load the 500 MB model
- recall_status() reports the last injection size for Hermes' recall
  indicator
- fix mirror data loss: deletions now key on the previous_content
  metadata and match exact content first, falling back to a substring
  match only when unambiguous; find_by_content split into find_exact
  and find_containing (instr-based, so % and _ stay literal)
- docs: AGENTS.org "Recall algorithm" section, Development prefetch
  section, corrected similarity-score explanation; version 1.1.1 -> 1.2.0

fix(plugin): declare python_dependencies for PM-built environments

Hermes Agent now assembles its runtime from PM dependency
generations instead of the legacy in-tree venv, so every update
produced a fresh environment without sqlite-vec and model2vec and
the provider reported itself unavailable until they were
reinstalled by hand.

Declare both runtime dependencies in plugin.yaml with upper bounds
per the Hermes dependency policy. PM reads the declaration of the
active memory.provider plugin and includes the packages in every
generation it builds, keeping the provider available across
updates without manual intervention.

Bump plugin metadata to 1.1.1, sync the AGENTS.org metadata table
and layout notes, and fix a wording slip in Documentation/index.org.

docs: sync Development page with source, modernize conventions

- fix retinue_memory_search schema block: limit default 10 -> 50 and
  descriptions synced with src/retinue/provider.py
- correct "cosine-similarity search" to KNN by L2 distance (vec0
  default), matching the retrieval section
- sync project-structure tree with the actual repo (import_holographic.py,
  system_prompt_block.txt, test/, Tools/lib, Open with IntelliJ IDEA,
  Development/index.org itself)
- add file-level drawer (:ID: + :CUSTOM_ID: development) and switch the
  back-link to the exported-anchor form
  (../index.html#outline-container-development)
- AGENTS.org: document the anchor back-link and file-level CUSTOM_ID
  conventions for sub-pages

fix(install): enable memory toolset so clean Hermes installs expose Retinue

Found on a fresh Hermes "Blank Slate" install (valeriapc, 2026-08-30):
Retinue installed and selected via memory.provider, hermes memory status
reported the plugin available — yet the session had no retinue_memory_*
tools and no Retinue system-prompt block. Blank Slate setup writes
platform_toolsets.cli = [file, skills, terminal, vision] and lists memory
in agent.disabled_toolsets; with that gate closed Hermes initializes the
provider but withholds its entire model-facing surface.

- Install Retinue now runs `hermes tools enable --platform cli memory`
  after setting memory.provider. Verified in Hermes source
  (tools_config.py _save_platform_tools) that this both adds the toolset
  to platform_toolsets.cli and removes it from agent.disabled_toolsets.
- Failure of that step is non-fatal but fully visible: captured output
  and the manual command are printed (no silent 2>/dev/null), plus a note
  that other platforms (telegram, discord, ...) each need their own
  --platform <name> enable.
- Docs: Documentation/index.org (five installer steps),
  Documentation/Development/index.org (full step list incl. the
  pip -> ensurepip -> uv dependency chain), AGENTS.org (deploy section +
  new Blank Slate memory-toolset pitfall).

Verified with a stubbed-environment ad-hoc harness (10/10): the stub
hermes CLI receives `tools enable --platform cli memory`; a CLI that
rejects it produces a warning with the captured error and manual command
while the install still completes. Live fix applied on valeriapc:
memory now in platform_toolsets.cli and gone from agent.disabled_toolsets.

fix(install): survive pip-less uv-created Hermes venvs; stop hiding errors

Found installing on a fresh Debian 13 machine (Hermes installed via its
own uv-based install.sh):

- Root cause: 'uv venv' does not seed pip into the Hermes runtime venv,
  so '$PYTHON -m pip install' died with 'No module named pip' and the
  installer's suggested manual pip command would have failed the same
  way. Dependency installation now chains: pip -> ensurepip-bootstrapped
  pip -> 'uv pip install --python' (uv probed on PATH and at
  $HERMES_HOME/bin/uv, covering non-login SSH shells with minimal PATH).
- No more silent failures: every fallible step (deps, model preload,
  hermes config set, plugin validation) captured stderr behind
  2>/dev/null, making the remote failure undebuggable. All of them now
  capture combined output into DIAG_DIR (cleaned via EXIT trap) and
  print a show_log_tail excerpt on failure; failure guidance names
  commands that actually work on a pip-less host (uv, ensurepip).
- Docs: Documentation/index.org step 2 describes the install chain;
  AGENTS.org gains the uv-venv-has-no-pip and no-silent-2>/dev/null
  pitfalls and the tooling note describes the new chain.

Verified with a stubbed-environment ad-hoc harness (20/20): pip-less
uv venv + broken ensurepip + uv present (exact remote repro) installs
via uv; pip-present venv uses pip; total failure prints captured
diagnostics and working manual commands. Canonical suite green.

fix(install): work on bare servers without PATH hermes or python3-venv

Found during first install on a fresh Debian 13 server:

- Installer now probes ~/.local/bin/hermes, ~/bin, /usr/local/bin and
  /usr/bin for the hermes CLI instead of relying on PATH alone.
  Non-login SSH shells never read ~/.profile, so "hermes CLI not found"
  fired and memory.provider was left unset.
- New shared Tools/lib/common.sh picks a working Python for all Tools
  scripts: project .venv (only if sqlite-vec + model2vec actually
  import — a failed python3 -m venv on hosts without the python3-venv
  apt package leaves a half-created venv that passes -x checks), then
  uv (bundled with Hermes at ~/.hermes/bin/uv), then the Hermes runtime
  venv. Broken half-venvs are recreated instead of trusted.
- Docs: prerequisites updated (no PATH / python3-venv needed), importer
  fallback and idempotency documented, systemd restart hint including
  the "Gateway already running (PID ...)" stale-lock case.
- AGENTS.org: Tools/lib layout entry and three new pitfalls.

initial commit