dynamics.py: potentiation and decay are never called

Really like the dynamics model — the Hebb/Ebbinghaus/Cepeda grounding is a nicer basis than most memory scoring I've read.

I've been reading through dynamics.py rather than actually running it, so I could easily be missing wiring I can't see — but as far as I can tell nothing calls potentiate or apply_decay:

$ grep -rn 'from .dynamics import' mempalace/
mempalace/palace_graph.py:33:from .dynamics import initialize_dynamics_fields
mempalace/hallways.py:45:from .dynamics import initialize_dynamics_fields

$ grep -rn 'apply_decay\|potentiate' mempalace/ --include='*.py' | grep -v dynamics.py
(no results)

So hall and tunnel records get strength, stability, last_activated and access_count backfilled once and then never updated — nothing strengthens on co-access, nothing fades with time. test_dynamics.py covers the functions themselves, so CI stays green. The module docstring says callers in those two files invoke them, and #1921 repeats that when proposing to extend the model to drawers, so it may be worth confirming either way.

One thing I ran into before in my own code, worth knowing before wiring it up: apply_decay multiplies the stored strength while only potentiate resets last_activated, so running it twice compounds.

base = {"strength": 1.0, "stability": 5.0, "last_activated": ten_days_ago}
apply_decay(once, now=day10)                              # 0.135335
apply_decay(twice, now=day5); apply_decay(twice, now=day10)  # 0.050000 (floor)

Same ten days, and the second one is pinned at the floor where it looks like a connection nobody has touched in a year — so strength ends up depending on how often maintenance ran.

PR with a read-time effective_strength that avoids that, plus a docstring fix: https://github.com/MemPalace/mempalace/pull/2416. It deliberately doesn't wire up the calls, since which access counts as a co-access seems like your call. Happy to follow up with that half if it's useful.