fix: address audit findings — SDK plumbing, TUI bus, dead code

Critical fixes:

- ``StrixOrchestrationHooks.on_agent_start`` now finds the
  ``CaidoCapability`` via ``ctx.context['caido_capability']`` instead
  of ``agent.capabilities`` (we use plain ``Agent``, not
  ``SandboxAgent``, so the latter never existed). The session
  manager's bundle already exposes the capability; ``run_strix_scan``
  threads it through ``make_agent_context`` and ``create_agent``
  forwards it to children.

- ``run_strix_scan`` registers the ``StrixTracingProcessor`` with the
  SDK's tracing provider via ``add_trace_processor`` so SDK trace
  spans hit ``run_dir/events.jsonl`` (was previously a parallel stream
  the SDK ignored).

- ``on_llm_end`` now writes to ``Tracer.record_llm_usage`` in
  addition to ``bus.record_usage`` so the CLI/TUI stats panel sees
  real numbers instead of zeros.

- ``run_strix_scan`` accepts an externally-built ``AgentMessageBus``
  + an explicit ``model`` arg. The TUI pre-creates the bus so its
  stop and chat-input handlers can submit ``bus.send`` /
  ``bus.cancel_descendants`` coroutines onto the scan thread's loop
  via ``asyncio.run_coroutine_threadsafe`` — replacing the
  TODO-stub no-ops.

- ``model`` config now propagates root → context → child agents in
  ``create_agent`` (was hardcoded fallback).

Dead-code removal:

- Deleted the ``load_skill`` tool entirely (host module, sandbox
  module, TUI renderer, tests). The legacy implementation reached
  into a global ``_agent_instances`` registry that no longer exists;
  the post-migration stub returned ``success=True`` without
  injecting anything — pure theater. Skills are still preloaded via
  the system prompt at scan-bring-up.

- Dropped ``tenacity`` and ``xmltodict`` from
  ``[project.dependencies]`` — neither is imported anywhere
  post-migration.

- Stripped the system prompt's "use the load_skill tool" lines.

Tests: 278/278 passing. Removed two ``load_skill`` test cases and a
``test_tool_registration_modes::test_load_skill_import_...`` assertion
that exercised the deleted module.

strix/agents/factory.py

@@ -21,8 +21,9 @@ Two flavors:
 
 Caido tools come from ``CaidoCapability.tools()`` automatically via
 the SDK's capability merge — we don't include them here. Skills are
-injected via the prompt; the model can also load more at runtime via
-the ``load_skill`` tool.
+injected via the prompt at scan-bring-up time; runtime skill loading
+isn't exposed as a tool any more (the legacy implementation reached
+into a global agent registry that no longer exists).
 
 References:
     - PLAYBOOK.md §4.3 (graph tool wiring)
@@ -54,7 +55,6 @@ from strix.tools.file_edit.tools import (
     str_replace_editor,
 )
 from strix.tools.finish.tool import finish_scan
-from strix.tools.load_skill.tool import load_skill
 from strix.tools.notes.tools import (
     create_note,
     delete_note,
@@ -109,8 +109,6 @@ _BASE_TOOLS: tuple[Tool, ...] = (
     search_files,
     # Reporting
     create_vulnerability_report,
-    # Skill loading
-    load_skill,
     # Sandbox primitives
     browser_action,
     terminal_execute,
@@ -140,8 +138,7 @@ def build_strix_agent(
         name: Agent name. Surfaces in traces and the bus's ``names`` map.
             Defaults to ``"strix"`` for the root; create_agent passes
             distinct names per child.
-        skills: Skills to preload into the system prompt. The agent can
-            also load more at runtime via the ``load_skill`` tool.
+        skills: Skills to preload into the system prompt.
         is_root: Selects the tool list and ``tool_use_behavior``.
             Root carries ``finish_scan`` and stops there; child carries
             ``agent_finish`` and stops there.

strix/agents/prompt.py

@@ -67,9 +67,7 @@ def render_system_prompt(
     """Render the system prompt.
 
     Args:
-        skills: Skills the caller wants preloaded into the prompt
-            context (the agent can also load more at runtime via the
-            ``load_skill`` tool).
+        skills: Skills the caller wants preloaded into the prompt context.
         scan_mode: ``"deep" | "fast" | ...``. Maps to ``scan_modes/<mode>``
             skill.
         is_whitebox: When True, the source-aware whitebox skill stack

strix/agents/prompts/system_prompt.jinja

@@ -148,9 +148,7 @@ OPERATIONAL PRINCIPLES:
 - Default to recon first. Unless the next step is obvious from context or the user/system gives specific prioritization instructions, begin by mapping the target well before diving into narrow validation or targeted testing
 - Prefer established industry-standard tools already available in the sandbox before writing custom scripts
 - Do NOT reinvent the wheel with ad hoc Python or shell code when a suitable existing tool can do the job reliably
-- Use the load_skill tool when you need exact vulnerability-specific, protocol-specific, or tool-specific guidance before acting
-- Prefer loading a relevant skill before guessing payloads, workflows, or tool syntax from memory
-- If a task maps cleanly to one or more available skills, load them early and let them guide your next actions
+- Skills relevant to your task are preloaded into this prompt at scan start; refer back to them when you need vulnerability-, protocol-, or tool-specific guidance
 - Use custom Python or shell code when you want to dig deeper, automate custom workflows, batch operations, triage results, build target-specific validation, or do work that existing tools do not cover cleanly
 - Chain related weaknesses when needed to demonstrate real impact
 - Consider business logic and context in validation