fix(venus-core): re-export notebook imports so they reach cells

[farhan-syah]

Problem

Imports declared in a notebook's IMPORT cell did not reach code cells. A notebook like:

use plotlars::polars::prelude::DataFrame;

#[venus::cell]
pub fn new_cell_1() -> DataFrame { /* ... */ }

failed to compile the cell with `DataFrame` not found in this scope, even though the import was present.

Root cause

Venus compiles a notebook's imports and type definitions into a shared venus_universe crate, then compiles each cell as its own crate that links the universe and glob-imports it (extern crate venus_universe; use venus_universe::*;). Definition-cell use statements were emitted into the universe as private use items, so their names were never re-exported and stayed invisible to cells. This affected the interactive paths (venus run, venus serve); the standalone venus build path was unaffected because it inlines imports.

The same broken invariant — definition-cell items must be public to reach cells — also applied to non-pub user types and helper functions.

Fix

A new syn-based definition_processor replaces the previous line-based rewriting in universe.rs. For each definition-cell item it:

• re-exports every use as pub use (imports now reach cells);
• promotes every top-level definition (struct/enum/type/fn/trait/const/static/union/mod) to pub;
• applies rkyv derives to structs/enums that carry a derive list (dropping serde's Serialize/Deserialize), so cell return values stay zero-copy serializable.

Imports are also folded into the universe cache hash so editing an import invalidates the cached build.

Tests

• Unit — definition_processor covers every import form (named/glob/aliased/multiple/mixed-cell), pub promotion of each item kind, no double-pub, and the rkyv-derive transform (adds rkyv, drops serde, no duplication, leaves derive-less types alone).
• Unit — universe asserts the generated crate re-exports imports as pub use, with a guard that fails on any private use (the silent failure mode).
• End-to-end — tests/import_propagation.rs compiles a real two-crate universe↔cell structure with rustc and loads it via dlopen, proving a pub use re-export reaches a glob-importing cell, plus a negative control that reproduces the original bug (a private use fails to compile the cell). Deterministic, std-only, no cranelift/network.

Validation

• cargo fmt / cargo clippy clean on changed files
• 225/225 venus-core tests pass
• cargo build --workspace succeeds
• Verified end-to-end: venus run on a notebook that imports and uses std::collections::BTreeMap now compiles and executes correctly

Closes #3