feat: api.slothlet.restart() — a clean-slate rebuild that swaps in a fresh instance behind the same api reference #504

Problem

reload() is deliberately not a clean slate. After a full reload, slothlet keeps:

1. References — api and any held leaf (api.math.add) keep working.
2. Runtime mutations — every api.slothlet.api.add() / remove() is replayed from the operation history (docs/RELOAD.md, "Operation History and Replay").
3. Runtime assignments — self.x = … overrides are flagged userAssigned and survive verbatim (O15, docs/API-RULES/API-COLLISION-CONDITIONS.md).

That is the right contract for hot-reloading code while an app keeps running, but there is no way to get the opposite: "throw away everything that happened at runtime and come back up exactly as a fresh slothlet({...}) would". Example:

// api/conn.mjs — the module's top level creates the emitter
import { EventEmitter } from "node:events";
const conn = new EventEmitter();
export default conn;

api.conn.handlers = { onSend }; // runtime assignment → userAssigned (O15)
await api.slothlet.api.reload(); // conn.mjs re-runs, but api.conn.handlers is still there

After a reload, api.conn is a new emitter from the module's top level, yet the runtime-assigned handlers is re-applied on top of it. For a "start over" there is currently nothing short of shutting the instance down and building a new one, which invalidates every reference callers hold.

Proposal

Keep reload() exactly as it is. Add api.slothlet.restart():

• Builds a new internal instance from the instance's original config (same as the slothlet({...}) call that created it).
• Swaps it in behind the existing api root proxy, so callers' references keep working, the same way reload preserves them.
• Shuts the old instance down through the normal teardown path (shutdown lifecycle, handler cleanup, permission/version manager shutdown()), so nothing from it leaks.
• Nothing runtime is carried over: no userAssigned overrides, no module-scope state from the old imports (fresh import, cache-busted as reload already does).

Open questions (decide before implementing)

1. Runtime add() / remove() history: replay it (restart = "fresh process with the same mounts") or drop it (restart = "exactly the original slothlet({...}) call")?
2. Runtime-registered hooks, permission rules and event subscriptions: carried over or dropped? Dropping matches "clean slate", but a caller that registered a hook at startup loses it.
3. Held child references: a caller holding api.conn (not just api) — should it re-point to the new instance's conn, as reload does, or is only the root reference guaranteed?
4. Lifecycle events: a new restart event, or shutdown (old) + init (new)?