[Foundation gap] No inertia tensor (Ixx/Iyy/Izz) and no 3D component placement in the vehicle schema

[aligatoralex]

Summary

ComponentStore/mass.py::MassProperties carries only total_mass_kg, cg_from_nose_m (1-D, longitudinal), and cg_source. There is no inertia tensor anywhere in YAADO_Core (grep for Ixx/Iyy/Izz/inertia finds nothing relevant), and BaseVehicleConfig has no per-component 3D placement/orientation — propulsion/aero_surfaces/bodies are flat name-keyed dicts with no x/y/z offset relative to each other.

Why it matters

This is a foundational gap, not a niche one:

• Any real 6-DOF flight dynamics or lateral/directional stability & control work needs the inertia tensor.
• Even a crude parallel-axis estimate is unsupportable today: longitudinal CG exists per component, but no lateral (y/z) placement and no per-component mass-distribution primitives mean Iyy/Izz can only be roughed in and Ixx (roll — needs radial mass distribution) essentially cannot be estimated at all.
• It blocks the X-Plane exporter idea (separate issue) and would block any future 6-DOF trajectory or dynamic-stability solver.

Options (likely its own RFC)

1. Extend the schema: add 3-axis component placement + simple mass-distribution primitives (point masses, rings, shells, cylinders) so a tensor can be integrated — kept generic per project rule RamP full-analysis rerun: stability / cycle / inlet / nozzle / cold-flow (post-research) #4.
2. Derive inertia from OpenVSP geometry (airframe/generator_methods/openvsp.py already exists; OpenVSP computes mass properties for components with assigned densities) — a nearer-term path that avoids inventing a Pydantic mass-distribution model.

Because this touches the core data model (composition, generic Core) and unblocks multiple directions, it likely deserves a dedicated RFC before implementation.

Discovery context

Surfaced by the MDO-directions research (see PR #42, docs/research/mdo-directions-2026.md, direction R5 / cross-cutting finding #4).