agent: fold Application-profile registry tools (#618/#622) into the built-in agent's toolset

## Context

The built-in agent (#626) consumes the unified MCP tool registry (#615) RBAC-filtered — but the **Operations profile (#617) only**. From `agent/registryTools.ts` (#1545, in the HarperFast/harper#1549 stack):

> The Application profile (#618) is intentionally out of scope here; it can fold in the same way once per-Resource tool generation is wired for the agent.

The fold-in is promised in that comment but tracked nowhere. This issue tracks it.

## Why

Components deployed on an instance can already contribute tools **in-process** via the registry: auto-generated per-Resource verbs (#618) and curated `static mcpTools` (#622). Folding the Application profile into the agent's toolset makes those tools available to the built-in agent automatically — no extra transport, and the same per-call enforcement the operations profile already gets (`hdb_user` set to the configured agent user, `verifyPerms` at dispatch; listing stays a convenience filter, not the boundary).

Concretely, this makes the agent's tool surface pluggable by deployment: a memory/recall component's `store`/`search` tools would let the agent persist and recall findings across sessions with zero agent-specific wiring; the same goes for a docs-search component or org-internal tooling. Combined with `agent.systemPromptAppend` (#1560), an operator can both mount the tools and tell the agent when to reach for them — entirely with existing machinery.

It also generalizes the pattern behind the hardcoded `harper_best_practice` tool (#1560), which is `extraTools`-injected today because no component-contributed path exists.

## Design questions

- **Visibility curation**: is HarperFast/harper#622's opt-in (`static mcpTools`) sufficient control over what the agent sees, or do tools need an agent-visible vs external-MCP-only annotation? HarperFast/harper#618 auto-generates verbs for every `@export`ed Resource — the agent seeing all of them by default may be noisy or undesirable.
- **Precedence**: operator-only tools win name collisions at composition (`agent/toolset.ts`); confirm the same precedence holds for application tools.
- **Late registration**: HarperFast/harper#1579 made operations-profile listing lazy so late-registered ops surface; application tools register at component load, so the agent's compose step needs the same behavior.

## Out of scope (future)

Mounting **external** MCP servers as agent tool sources (an `agent.mcpServers` config) — the remote variant of the same idea. In-process components cover the same-instance case without a transport, so that can be weighed separately.

Refs: HarperFast/harper-pro#676, HarperFast/harper#615, HarperFast/harper#617, HarperFast/harper#618, HarperFast/harper#622, HarperFast/harper#1545, HarperFast/harper#1560, HarperFast/harper#1579.

🤖 Posted by [Claude](https://claude.com/claude-code) on behalf of @heskew

Start by reading agent/registryTools.ts and agent/toolset.ts, then review the referenced Application profile work in #618 and #622 and the lazy listing change in #1579. Determine how generated Resource verbs and static mcpTools should be composed with the built-in agent, including visibility, precedence, and late registration. Done means Application-profile tools are available in-process with the existing per-call permission enforcement and without external MCP servers.

Written by the indexing model from the issue text.