refactor(core): extract loomweave-llm crate (remove outbound HTTP from the plugin-host/SEI crate)

[tachyon-beep]

What

Extracts the LLM + embedding providers out of loomweave-core into a new pure-leaf crate loomweave-llm, so the plugin-supervisor + SEI crate no longer links an outbound HTTP client (reqwest).

Behavior-preserving lift-and-shift. The two provider modules (llm_provider.rs, embedding_provider.rs) move verbatim (incl. their #[cfg(test)] modules — git records them as R100 renames); loomweave-core drops reqwest/async-trait/fs2; loomweave-cli and loomweave-mcp repoint their provider imports loomweave_core::… → loomweave_llm::…. No provider behavior changes; no per-provider split (that is the downstream bet clarion-4328c5c757).

PRD-0001 / PDR-0003. Tracker: clarion-141e9c08c8 (head of the critical path → unblocks clarion-4328c5c757).

Why

loomweave-core is two crates wearing one coat: it forks sandboxed plugin subprocesses and mints stable entity identity (SEI), yet also carried ~3,660 LOC of outbound model HTTP and pulled reqwest into the dependency tree for every dependent. The crate that runs untrusted forked children and mints identity tokens should not also open network sockets to a model provider.

Trust-surface invariant (now enforced)

cargo tree -p loomweave-core --edges normal resolves no reqwest. A new CI gate in verify.yml fails the build if reqwest re-enters loomweave-core's tree — a per-crate ban cargo-deny's [bans] cannot express (reqwest stays legitimate in loomweave-federation/loomweave-cli). The gate uses cargo tree --prefix none (a bare ^reqwest against the tree output never matches an indented dep and would pass vacuously) and captures the tree under set -euo pipefail so a cargo tree error fails the gate rather than being swallowed.

Acceptance (PRD-0001, all 6 verified locally)

1. Structural — core resolves no reqwest; both provider modules live in loomweave-llm. ✅
2. Metric (trust-surface) — yes → no flip + CI assertion. ✅
3. CI floor — fmt, clippy -D warnings, build, nextest (1948 passed / 2 skipped under CI-equiv), doc -D warnings, deny, ruff, ruff-format, mypy --strict, pytest (220 passed), + all 3 e2e scripts. ✅
4. Identity — entity_id.rs untouched; no SEI/identity code moved. ✅
5. No consumer regression — cli + mcp tests pass; RecordingProvider/RecordingEmbeddingProvider replay tests pass unchanged. ✅
6. Pure lift-and-shift — moved files are R100 renames (zero content delta). ✅

Notes

• Pre-existing, unrelated local-floor item surfaced during verification (does not block this PR): the wardline_taint_fact_conformance_oracle vendored golden has drifted from the ~/wardline authority — confirmed failing on pristine main; this branch touches neither input. Filed as clarion-72e1c1a07d (CI stays green via the oracle's skip-clean when the sibling repo is absent).

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 14ca42f59a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Publish loomweave-llm before dependent crates

On a tagged release, this new versioned dependency has to resolve from crates.io after Cargo strips the local path, but I checked the publish-crates job in .github/workflows/release.yml:512-519 and it publishes core/scanner/analysis/storage/federation/plugin-rust/mcp/cli without ever publishing loomweave-llm. The first release containing this split will therefore fail when publishing loomweave-mcp (and then loomweave-cli); add publish loomweave-llm before the dependent crates in that workflow.

Useful? React with 👍 / 👎.