cleanup: extract `module_path` from `RelationshipMeta` — Rust-specific, doesn't belong in Lemon shape

[i-am-logger]

Context

RelationshipMeta (the unified Lemon + PROV-O record shared by every structural entity in pr4xis) has four fields:

• name: OntologyName — ONTOLEX-Lemon canonical form
• description: Label — Lemon Form label
• citation: Citation — PROV-O provenance
• module_path: ModulePath — Rust module location (implementation-specific)

The first three are literature-standard (Lemon + PROV-O). module_path is a Rust implementation detail leaking into what should be an ontology-standard shape.

Proposal

Move module_path to a separate ImplementationLocation record keyed by name:

#[derive(Debug, Clone)]
pub struct RelationshipMeta {
    pub name: OntologyName,
    pub description: Label,
    pub citation: Citation,
    // module_path removed
}

/// Rust-specific where-in-the-codebase metadata. Orthogonal to the
/// Lemon/PROV-O ontology description — useful for tooling, debugging,
/// and cross-referencing.
#[derive(Debug, Clone)]
pub struct ImplementationLocation {
    pub name: OntologyName,
    pub module_path: ModulePath,
}

Plus a parallel registry IMPLEMENTATIONS distributed slice keyed by name, so consumers that want Rust location info can still get it.

Why deferred

• Cosmetic: nothing breaks today, module_path just sits in a shape where it's arguably out of place.
• Cascade cost: every relationship_meta! / axiom_meta! macro invocation emits module_path!(). Extracting it means updating the macros and the ~100 manual RelationshipMeta { ... } construction sites across core + domains.
• Consumer impact: any code reading meta.module_path would need to switch to the new parallel registry.

When to pick up

When an external tool / paper / spec refers to pr4xis's RelationshipMeta shape as THE Lemon description format, and the Rust leakage actively confuses something. Until then, carrying the field as "implementation annotation in a Lemon-shaped wrapper" is harmless.

Literature

• ONTOLEX-Lemon (W3C 2016) — LexicalEntry shape
• PROV-O (W3C 2013) — provenance fields (wasGeneratedBy, wasAttributedTo, hadAgent)
• VoID (W3C 2011) — vocabulary self-description