Annotate every ``list[*]`` field in config.py with an explicit merge
strategy via ``typing.Annotated`` so future fragment-based loaders
(``~/.memtomem/config.d/``) can pick append vs replace semantics per
field instead of inferring from the type. Keeps the declaration
co-located with the field and makes the strategy part of the type
annotation rather than a separate registry.

- ``APPEND`` (4 fields): memory_dirs, exclude_patterns,
  system_namespace_prefixes, webhook.events — elements are independent,
  duplicates dedup on merge.
- ``REPLACE`` (2 fields): rrf_weights, importance.weights — positional
  tuning knobs where element order/length is semantic; highest-priority
  source wins entirely.

No runtime behaviour change yet; loader landing in a follow-up commit
will read the ``MergeStrategy`` via ``FieldInfo.metadata``.

New ``load_config_d`` scans ``~/.memtomem/config.d/*.json`` in
lexicographic filename order and merges each fragment into the running
config. Intended for integration-installed drop-ins: ``mm init
<client>`` writes one fragment, ``mm uninstall <client>`` removes it.
Idempotent, no mutation of shared state.

Merge rules per field (strategy from ``MergeStrategy`` annotation):

- APPEND list → concatenate with current list, dedup by value
  (``Path`` normalised to string form for comparison).
- REPLACE list → fragment value replaces whatever was there.
- Scalar → last fragment applied wins.
- ``MEMTOMEM_<SECTION>__<FIELD>`` env var set → fragment value for that
  field is skipped (env wins, same rule as config.json).

Layering in ``create_components`` (lowest → highest priority):
defaults → config.d/*.json → config.json → env. ``config.json`` keeps
its current REPLACE-on-set semantics so the ``mm init`` wizard UX
("set my memory dir to X") is unambiguous; fragments are the layer
that respects per-field merge strategies.

Invalid fragments (malformed JSON, non-object top level, unknown
sections) are logged and skipped without crashing startup, matching the
existing ``config.json`` resilience.

Adds ``test_every_list_field_declares_merge_strategy`` that walks every
``Mem2MemConfig`` section and fails if a ``list[*]`` field lacks a
``MergeStrategy`` annotation in its metadata. The failure message lists
the offending fields and tells the contributor to wrap the type in
``Annotated[list[X], APPEND]`` or ``Annotated[list[X], REPLACE]``.

Guards against silent fragment-merge footguns: without this, someone
adding a new positional ``list[float]`` tuning knob without declaring
REPLACE would let a ``config.d/`` fragment accidentally append to it
via the default-to-REPLACE fallback.

Adds a "Precedence and merge behaviour" section to
``docs/guides/configuration.md`` covering the full resolution order
(defaults → ``config.d/*.json`` → ``config.json`` → env vars) and a
table of which ``list[*]`` fields use APPEND vs REPLACE under the
fragment layer.

Also amends the auto-discovered-memory-dirs note to mention the new
``config.d/`` layer alongside ``config.json`` so it stays accurate.

Other integration docs (``mcp-clients.md``, ``cloud-sync.md``,
``integrations/*``) already advertised the env-wins semantic that this
branch just made true in the code, so no wording change is needed there
— the advertised examples now work as documented.

(Commit also folds in ``ruff format`` over ``config.py`` and the new
test file, a no-op reflow of the lines touched in earlier commits.)

…/ embedding-reset)

``mm config show`` and the ``reset`` / ``embedding-reset`` diagnostics
only called ``load_config_overrides`` before the new fragment layer
landed, so ``config.d/*.json`` contributions (e.g. an integration's
``exclude_patterns`` APPEND) were invisible to these commands even
though the running server sees them. Add ``load_config_d`` before
``load_config_overrides`` in all three read-path call sites so the CLI
tells the truth about what the runtime resolves.

``config_set`` is intentionally left alone — ``save_config_overrides``
uses read-merge-write over ``MUTABLE_FIELDS``, so pulling fragment
values into the runtime before save would risk baking fragment state
into ``config.json`` (where it would persist past the fragment file's
removal). Fixing that is a separate refactor of ``save_config_overrides``
to track field provenance; out of scope here.