fix(pi-fff): preserve FFF tool renderers for historical calls after `/reload`

## Summary

`pi-fff` registers its tools in `session_start`, but Pi restores historical tool rows before it emits that event. After `/reload`, existing `ffgrep` and `fffind` rows therefore cannot resolve their custom `renderCall` / `renderResult` functions and fall back to the generic tool display. Calls made after the reload render normally.

This predates #851. #851 makes the problem more visible because its compact renderer is lost after reload, but does not introduce the lifecycle mismatch.

## Reproduction

1. Start Pi with `pi-fff` in its default FFF-named mode.
2. Call `ffgrep` or `fffind`.
3. Run `/reload`.
4. Inspect the pre-reload tool row.

## Actual

The historical row displays the tool name, JSON arguments, and raw output through Pi's generic fallback.

## Expected

The historical row uses the same `pi-fff` renderer as a newly created row in the same session.

## Screenshot

## Scope

A fix can register the non-builtin FFF-named definitions during extension loading so historical rows can resolve their renderers. It must leave final tool activation, mode restoration, search execution, arguments, and model-visible results in `session_start`.

Historical override-mode `grep` / `find` rows are outside this narrow fix: registering those names before mode restoration would override Pi's built-in names too early.

Start at the pi-fff extension-loading path and the session_start handler, then trace how /reload restores historical tool rows and resolves renderCall/renderResult. Reproduce with ffgrep or fffind before and after /reload; done means historical rows use the pi-fff renderer while final activation, mode restoration, search execution, arguments, and model-visible results remain unchanged.

Written by the indexing model from the issue text.