Wiring: slot for extension plugins that are registered only after unlock #894

Goal

"Commands of extension plugins are only reachable after unlock" becomes a guarantee of the core instead of a convention each plugin has to follow: in master-password mode, plugins registered through a new Wiring slot are added to the app only after unlocking, exactly like the core's own plugins that touch files, settings or the OS.

Context

• crates/app-shell/src/wiring.rs:28 pub type PluginHook = Box<dyn FnOnce(Builder<Wry>) -> Builder<Wry> + Send>; the doc comment at :33-38 requires hooks that register commands to do so only after unlock in password mode (ADR 0095 §8) – but a builder hook can only act at build time.
• crates/app-shell/src/lib.rs:637-643 folds all wiring.plugins into the builder before the unlock decision (defer_plugins, :661-671). The startup gate does not see plugin commands (startup_gate.rs module doc, measured M7), so every extension plugin command is callable while the app is locked; each plugin has to check the lock state itself.
• The core already solves this for its own plugins: register_unlocked_plugins_on (lib.rs:1079-1118, keyring mode, at build time) and register_unlocked_plugins (lib.rs:1127-1160, password mode, via AppHandle::plugin after unlock, called from commands/master_password.rs:667), with UnlockedPluginsPendingSlot (lib.rs:1162-1171). Measured M9: a plugin registered after build() is unreachable before ("plugin … not found"), even if the ACL allows it.
• Test harness to reuse: crates/app-shell/src/startup_gate_wiring.rs (mock app, get_ipc_response, ACL opened via __allow_command).

Requirements

• New Wiring field pub plugins_after_unlock: Vec<UnlockedPlugin> with
  pub type UnlockedPlugin = Box<dyn FnOnce() -> tauri::plugin::TauriPlugin<Wry> + Send> (or an equivalent factory type that works with both Builder::plugin and AppHandle::plugin). Community: empty.
• Keyring mode (state available at start): the factories run at build time, right after the core's register_unlocked_plugins_on.
• Password mode: the factories run in register_unlocked_plugins after the gate opened and after the core plugins, in registration order. A failing registration is logged at error with the plugin name and does not stop the others or the unlock.
• They run exactly once per process (unlock after a lock-less restart path must not register twice – same UnlockedPluginsPendingSlot logic).
• PluginHook doc comment: hooks in plugins run before unlock; extension plugins with commands that need an unlocked app belong in plugins_after_unlock.
• Spec 0038 ("Master-Passwort-Modus" paragraph) and Spec 0101 (A16 / Klarstellung 9) state the guarantee.

Acceptance Criteria

• Wiring::plugins_after_unlock exists, empty for Community (test).
• Test (analogous to startup_gate_wiring.rs, real IPC path with the mock runtime): a test plugin with one command, registered through plugins_after_unlock, answers "plugin … not found" (or Tauri's equivalent error) while the app is locked, and answers with its data after the unlock path ran register_unlocked_plugins.
• Test: in keyring mode (state present at start) the same plugin command is reachable right away.
• Test: a factory whose plugin fails to register (e.g. duplicate name) is logged and the next factory is still registered.
• Existing startup-gate and unlock tests pass unchanged.
• Specs 0038 and 0101 updated.
• Relevant automated tests pass (cargo test --workspace, clippy with -D warnings).

Technical Notes

• Security-relevant: startup gate / master-password unlock (Spec 0101 A16). Read .claude/skills/smart-ssh-coder/references/security-invariants.md. Order on unlock stays: manage state → open gate → register plugins → post-startup tasks (master_password.rs:640-670).
• Files: crates/app-shell/src/wiring.rs, crates/app-shell/src/lib.rs, crates/app-shell/src/startup_gate_wiring.rs (or a sibling test module), docs/specs/0038-repository-app-shell-ci.md, docs/specs/0101-*.md.
• Wiring is consumed partly by value in run() (lib.rs:637); move the new list into the pending-startup state the same way services are moved (lib.rs:638).

Spec impact: update 0038, update 0101

Open questions

• Factory type: Box<dyn FnOnce() -> TauriPlugin<Wry> + Send> (recommended; works with both Builder::plugin and AppHandle::plugin) or a trait object that applies itself to either target – pick whatever compiles without unsafe and keeps both paths on one list.

Related Work

• Wiring: service slot for background services that start after unlock and stop on lock and quit #669 (service slot that starts after unlock), ADR 0095