[Refactor] Architecture & SRP audit across core.next: single responsibility, naming, and package partitioning #643

Summary

Perform a systematic architectural and design audit across the core.next module to ensure adherence to the Single Responsibility Principle (SRP), clean naming conventions, modular decomposition, and cohesive package partitioning.

Objectives & Scope

1. Single Responsibility Principle (SRP)

• Audit classes, interfaces, and records across core.next to verify that each component has one single, well-defined reason to change.
• Identify oversized coordinator classes or classes mixing data structures, execution logic, and I/O or state management.
• Extract cohesive helper abstractions, strategies, or immutable records where responsibilities overlap.

2. Naming Conventions & Semantics

• Ensure class, interface, method, and variable names reflect domain semantics unambiguously without misleading or historical jargon.
• Harmonize terminology across modules (e.g. Statement vs Triple vs Quad, Store vs Storage, Producer vs Executor).
• Verify interface and implementation symmetry (*Operations, *Factory, *Snapshot, *Registry).

3. Granularity & Modular Decomposition

• Evaluate method and class granularity: prevent god-classes and premature over-fragmentation.
• Ensure proper separation between public SPI contracts (api), internal SPI abstractions (spi), and concrete implementations (impl).
• Confirm encapsulation: verify package-private visibility for internal implementation details to minimize exposed API surface.

4. Package Structure & Architectural Partitioning

• Review package distribution across sub-domains:
  • fr.inria.corese.core.next.data: RDF 1.1 value factory, models, literals, IRIs.
  • fr.inria.corese.core.next.storage: InMemoryStatementStore, indexes, concurrency, snapshots, transactions.
  • fr.inria.corese.core.next.query: SPARQL compilation, planning, cost-based ordering, execution pipeline.
  • fr.inria.corese.core.next.io: parsers, serializers, streaming readers, content negotiation.
• Eliminate circular package dependencies and ensure architectural boundary enforcement passes (NextModuleBoundaryTest).

Acceptance Criteria

• Comprehensive audit performed across core.next.* packages.
• Identified SRP violations or naming ambiguities refactored or tracked with targeted follow-up PRs.
• 0 SonarLint issues (cognitive complexity < 15, clean typing, boy scout compliance).
• Architectural boundary constraints in NextModuleBoundaryTest remain 100% compliant.
• 100% test pass rate across all existing unit tests and W3C conformance suites.