Counted orbital-year conversion still falls back to one Earth year
At slim 10.0 0e0e858238cb028b751a85a23f4690a0b0d48483, the shipped astronomy-v3 chain still substitutes a one-year table lookup for a counted orbital-year conversion. This is separate from PR #2's usage/geometry changes.
Reproducer from the repository root; it calls the actual current specialist with only the two table rows supplied explicitly, so no download or full Engine is needed:
import sys
sys.path.insert(0, 'root/specialists/astronomy-v3')
from organ_astronomy_v3 import AstronomyOrganV3
organ = AstronomyOrganV3.__new__(AstronomyOrganV3)
organ.bodies = ['Earth', 'Mars']
organ.v = {('Earth', 'Orbital Period (days)'): '365.25',
('Mars', 'Orbital Period (days)'): '687'}
print(organ.answer('Earth takes 365.25 days to orbit the Sun and Mars takes 687 days. How many Earth years are 3 Mars years?'))
Observed again on that 10.0 source: kind=year_years, value 1.0, “A year on Earth lasts about 1.00 Earth years”. Expected: 3 * 687 / 365.25 = 5.64271047227926 Earth years. The first mentioned body and one-year fallback lose the requested count and direction.
A reviewed proposed repair is already public: nine-copy astronomy patch, with scope, 21-case independent expectations and qualification details. It binds count, source/target bodies and source/target periods, identifies table versus supplied periods, and rejects conflicting or unused conditions. All four versioned specialist chains need the fix so an older copied module cannot revive the wrong fallback.
The patch's recorded tests and full-Engine checks were against our 4.9-based candidate. The current 10.0 component counterexample above is newly rerun; the 10.0 whole Engine and release gate were not. No existing verdict or release hash should be treated as qualifying modified code. Filing this independently keeps that adaptation/admission decision visible rather than silently bundling it with unrelated repairs.