feat(resolver): expose portable executable program IR

[levi770]

Problem

Downstream consumers currently have to reconstruct executable XLOG semantics from source text or from process-local AST details. That duplicates frontend/resolver logic, loses exact import-selection provenance, and cannot safely carry interned symbol identifiers across a process boundary.

Implementation

• Adds ModuleResolver::resolved_program_extraction(source_root) as the production structured extraction boundary.
• Emits portable, serde-serializable executable IR with resolved symbol strings and IEEE-754 probability bits.
• Reuses the canonical resolver import graph and production stratification analysis rather than reimplementing resolution or SCC logic.
• Extends the canonical import merge with ProgramMergeReport, recording only declarations and clauses actually admitted after private/selective filtering and deduplication. Provenance therefore follows the real merge operation, not textual equality heuristics.
• Covers deterministic rules, constraints, deterministic queries, domains, predicate schemas, recursive function bodies, probabilistic facts, annotated disjunctions, evidence, probabilistic queries, neural predicates, and learnable rules.
• Emits typed relation definitions, typed ordinary/negative/aggregate/epistemic dependencies, producer kind, SCC membership, stratum, and non-monotonicity.
• Adds xlog extract --source-root ... <entry> for end-to-end resolver-to-JSON execution. Existing xlog manifest remains available for the source-only view.
• Keeps exact parser-owned source bytes in ModuleResolver so source provenance cannot silently drift between parse and extraction.
• Fixes ParserSession::split_statements so the valid univ operator =.. is not split at either dot.

Behavioral evidence

• Selective/private import test proves that identical clauses from two modules are attributed only to the module whose clause the merge actually admitted.
• Structured-term test covers list, cons, compound, aggregate, and univ forms through the real resolver path.
• Probabilistic/learnable test covers probability bits, annotated choices, evidence, probabilistic queries, neural labels, learnable dependencies, and relation indexing.
• Domain/function test covers domain aliases, predicate schema types, recursive function-body serialization, arithmetic binding, and comparison literals.
• CLI tests launch the built xlog process, parse its JSON, inspect executable rules and query relations, and verify source-root rejection.

Verification

On rebased commit 44c59a4a571aa2b33872401b59e9ec86d2b38774:

• cargo fmt --all -- --check
• cargo clippy -p xlog-logic -p xlog-cli --all-targets -- -D warnings
• cargo test -p xlog-logic --test resolved_program_extraction --test resolved_program_manifest --test test_v085_incremental_parse -- --nocapture (18 passed)
• cargo test -p xlog-cli --test extraction_cli_tests -- --nocapture (2 passed)

Before the conflict-free rebase, cargo test -p xlog-logic also completed successfully across the full crate test surface, including 391 library unit tests and all integration binaries.

Scope and limits

• This PR changes XLOG only. It does not add or modify a Mistaber consumer.
• It exposes the resolved executable semantic structure; it does not execute inference or claim backend/GPU performance.
• Imported probabilistic, neural, and learnable definitions remain governed by the resolver's existing import policy; this PR does not broaden that language rule.
• The full xlog-cli suite was not used as completion evidence because its long-running explain_cli_tests exceeded the 120-second harness limit. The extraction CLI E2E target passed independently.
• No merge is requested or performed by this automation run.

Branch topology

This PR is independent of the Pyxlog/runtime stack in #286-#289 and targets main directly.