Add plugin agent types: agents a plugin defines and the app runs - #621

[P2] Fence the originating run after the credential wait

A publish can enter native while its run is valid, then block on a cold Keychain read at lines 1385–1391. If the run times out, settings are saved, or the plugin/session is replaced before that read completes, this check still succeeds: plugin_identity checks the current enabled flag and pubkey, not the originating run or saved revision. Stop→Start also passes because it restores enabled without changing the revision. The stale event is then sent for the first time after revocation, potentially during a newer run, contrary to the per-run guarantee in docs/plugin-architecture.md:1007–1012.

Carry a run lease/generation and deadline across IPC and revalidate it, plus the saved revision, after credential acquisition and immediately before send. Invalidate it on the documented cancellation paths, including Stop→Start. Add a gated-credential regression asserting no HTTP send after revocation. A JS service probe reproduces the missing cancellation boundary; the native credential/send ordering was source-traced, not exercised against real Keychain.

[P2] Do not retry a denied credential unlock on every automated publish

credentials.retry() clears the shared bundle's Denied latch (credentials/bundle.rs:23–26). After a user refuses an unlock, the next incoming event that causes this agent to publish therefore retries the OS credential operation without another user action. This directly violates Credentials::retry's deliberate Start/Retry contract (secret.rs:204–205) and the existing denial-persistence test; automatic traffic must not repeatedly reopen a refused unlock.

Remove the unconditional retry from publication and expose recovery through an explicit user-controlled Start/Retry path. Cover denial followed by multiple automatic publishes, then an explicit retry. The latch reset is confirmed from source; repeated native dialogs were not tested.

[P2] Supply the type registry at every editor entry point

This validation makes plugin-agent Save depend on agentTypes, but only the Agents-page caller supplies it. ProfileRuntime.tsx:232, ProfileAgentRuntime.tsx:101, and AgentUpdateReview.tsx:260 omit the registry; the profiles plugin does not inject it either. Opening an enabled plugin agent from its profile therefore falsely reports that its type is unavailable and rejects even a name change.

An RTL probe mounted ProfileAgentRuntime with a registered active type: opening the editor and saving a changed name produced the unavailable-type error and no save call. Passing the same registry directly to AgentEditor displayed the configuration form. Thread the registry through all supported entry points and cover those mounts. The profile runtime surface also needs to omit process-only controls such as Start on launch and Harness log for these agents.

[P2] Provide an explicit removal action for saved optional secrets

Blank input intentionally preserves a saved value, but this form has no other path that emits the native deletion patch ({ TOKEN: null }). Unlike harness agents, plugin agents do not render AgentEnvironmentEditor's Remove control. Once an optional token is saved, the user cannot remove it from this agent through the UI while keeping the identity; typing a replacement and clearing it only sends {} and retains the old token.

Add a host-owned “Remove saved value” action that sends null, with required-secret validation still enforced. Also allow removing saved secret names a later type version no longer declares. An RTL probe confirms that clearing the input produces an empty environment patch and that no remove/clear/delete action is rendered.

[P3, optional] Keep the harness worker seed conditional on the selected runtime

Harness → plugin → Harness resets environment to {}, losing the documented BUZZ_ACP_AGENTS=10 default for a new harness agent. Conversely, duplicating a plugin agent takes the unconditional seed at line 91 and saves this process-only override onto an agent whose form cannot remove it. Seed the worker override only for harness drafts, both on initialization and when switching back; add cases for switching and plugin duplication. Source-traced; not a merge blocker on its own.

[P3, optional] Describe the window-dependent live-input limits

The new listener receives accept()'s visibility-filtered output, not every live wire event. eventVisibility requires locally retained evidence for every e target of reactions, edits and deletions, even with a valid h tag. Thus a live reaction to an older, unloaded message can be dropped while the socket is healthy, and two windows can deliver different inputs. The stream also includes previewed channels, not just joined ones. Please document these limits rather than weakening the existing access check to obtain wider delivery.

Also clarify that leaving a channel stops new delivery but does not cancel events already queued in AgentTypesService; the service receives no channel-access revocation signal. These are source-traced contract clarifications, not requests to add subscriptions or reliable catch-up in this cut.

[P3, optional] Validate timeout overrides before registration

register validates concurrency but accepts timeoutMs: -1 (confirmed by a focused probe). AbortSignal.timeout(-1) then throws here, before the try, so the failure bypasses the promised error counter and becomes a rejected fire-and-forget execution. Reject invalid/non-integral timeout values during registration, or construct the signal inside the handled path. This is invalid-plugin-input hardening, not a blocker for correctly configured types.