Add render tool: synthetic Earth-limb imagery for EarthLim testing

[j4lando]

Closes #9.

What this adds

A new render tool (found_tools.render, CLI entry point found_tools_render) that generates synthetic Earth-limb test imagery for EarthLim and similar attitude-determination tools, following the DIY pipeline proposed in #9:

• geometry.py — Sun direction (ECI) and ECI→ECEF rotation for a given UTC datetime.
• textures.py — picks the date-appropriate Blue Marble Next Generation texture (by month) and the generic cloud layer texture.
• scene.py — packages Sun vector, camera intrinsics (reusing found_tools.utils.Camera), camera pose, and texture filenames into a JSON-serializable scene description.
• main.py — the found_tools_render CLI: parses date/camera/position/attitude/texture-dir args, writes the scene JSON, and (with --render) calls blender_scene.render_scene in-process to build and render it.
• blender_scene.py — the only module that imports bpy; builds the Blender scene (Earth + cloud sphere, Sun lamp along the computed vector, a sun-direction-aware atmosphere shell for limb glow/terminator softening, camera intrinsics/pose matched to the scene JSON) and renders it with Cycles.
• src/found_tools/render/README.md — usage docs, including the texture-download caveat from Add a synthetic Earth-rendering tool for generating EarthLim test imagery #9 (no month-by-month cloud product exists, so the cloud layer is generic) and a "Choosing camera parameters" section on avoiding a too-narrow FOV / too-close camera.

bpy (Blender as a Python module) is a real project dependency (Python pinned to >=3.13,<3.14 for wheel availability), so --render works standalone with no separate Blender install required.

Design notes / tradeoffs

• Ephemeris library: Add a synthetic Earth-rendering tool for generating EarthLim test imagery #9 suggested spiceypy or astropy. I used a closed-form, low-precision analytical Sun-position formula (Vallado, Fundamentals of Astrodynamics and Applications, Alg. 29) and the IAU 1982 GMST polynomial for ECI→ECEF instead of either library. The analytical formulas are accurate to ~0.01°, more than sufficient for lighting/texture selection in synthetic test imagery, and they're fully offline-testable, avoiding a SPICE kernel download or IERS data dependency in this repo's fail_under = 100 CI. If a project later needs higher precision, spiceypy/astropy can be swapped in behind the same function signatures.
• blender_scene.py is excluded from ty check — bpy ships no type stubs, so ty can't resolve its dynamically-generated attributes (bpy.context, bpy.ops, etc.). It's still exercised by real tests (see below).

Render bug fixes

I actually ran bpy.ops.render.render end-to-end (not just the unit tests) against real Blue Marble imagery and visually inspected the output at each step, through two rounds of fixes:

Round 1 — render came out as a blurry, overexposed mess:

1. Missing smooth shading (the main cause of the "blurry mess"). The Earth/cloud/atmosphere UV spheres were never smooth-shaded, so each of their ~256×128 quad faces rendered with one flat normal. Under smooth, low-contrast lighting (open ocean near the terminator) that regular lat/long face grid showed up as a persistent, screen-space-aligned checkerboard of brightness steps. I confirmed this wasn't denoising or adaptive sampling (reproduced identically with both off) or the atmosphere shell (still present with the shell removed) before finding the real cause. Fixed with bpy.ops.object.shade_smooth() on each sphere.
2. Overexposure. add_atmosphere() used Blender's Sky Texture node as the World background. That node models a ground-level sky dome, so as a World background it lit the entire background in every direction (not just near Earth's limb) with its own bright, independent default sun unrelated to the scene's actual Sun lamp — blowing out roughly half of every render to solid white. Replaced with a black deep-space World background plus a Fresnel-driven emission shell around the Earth, so the glow is strongest at grazing viewing angles (the limb) and fades toward the disk's center.
3. README example camera parameters were a bad example, not a code bug. --position 7000000 0 0 with a 50mm-equivalent lens put the camera at only ~622 km altitude with a ~5.5° field of view — a telephoto shot of a few-km ocean patch magnified to fill the frame. Swapped the example for parameters that produce a full Earth disk, and added a README section explaining how FOV, camera distance, and Earth's angular size interact.

Round 2 — the round-1 limb glow was a uniform white halo regardless of where the Sun was:

The Fresnel-only glow shell from round 1 glowed the same on the day and night side of the limb — physically wrong. add_atmosphere() now also takes the scene dict and masks/colors the glow by dot(surface normal, Sun direction) (the same Sun vector already driving the Sun lamp), on top of the existing view-angle Fresnel term:

• Fresnel still shapes where on the sphere the shell is visible (the limb vs. the disk center).
• A Sun-facing term (Geometry Normal · Sun direction, both in world/ECEF space) masks that down to the sunlit crescent via a Map Range that fades in just before the terminator and out on the night side, instead of a hard cutoff.
• A ColorRamp keyed off the same dot product shifts the glow from warm orange right at the terminator (long atmospheric path, like a ground sunset) to blue further into daylight (shorter, bluer-scattering path).

Verified across three viewpoints: near-subsolar (uniform bright rim is correct there — the whole visible limb really is sunlit), perpendicular-to-sun (glow present on the sunlit limb, absent near the terminator), and a pulled-back full-disk view confirming the day/night asymmetry and the warm-to-blue color shift right where the terminator meets the limb.

Test plan

• just check-all (lint, 100% coverage, tests, ty check) passes, including tests against the real bpy module: smooth-shading on all three spheres, atmosphere world background + shell material, the sun-direction node wiring (Geometry Normal → dot product with a normalized sun_vector_ecef → Map Range → emission strength/color), the warm/blue color ramp stops, and actual bpy.ops.render.render calls
• Manually ran the full render pipeline against real downloaded Blue Marble imagery and visually inspected output at every step of both fix rounds (not just relying on unit tests/coverage)

[j4lando]

Pushed another round of fixes on top of the render-quality pass (blurry mess -> limb glow, directional glow):

Earth modeled as a WGS84 ellipsoid, not a sphere. The Earth mesh (and the concentric cloud/atmosphere shells) were built with bpy.ops.mesh.primitive_uv_sphere_add(radius=...) -- a true sphere. WGS84's ~21 km polar flattening (equatorial radius 6,378,137 m vs. polar radius 6,356,752.314245 m, ~1/298.257) is small relative to Earth's radius but matters for accurate EarthLim limb-fitting. All three meshes are now built via a new _add_wgs84_ellipsoid() helper: a sphere at the equatorial radius with its local Z axis (Earth's rotation axis, matching the ECI/ECEF convention already used in geometry.py) scaled down to the WGS84 polar radius and baked into the mesh via transform_apply, so the cloud and atmosphere shells stay concentric with, and share the flattening of, the Earth mesh.

Since ~0.3% flattening isn't distinguishable by eye at normal camera framing, I verified this mathematically rather than visually: new tests compute the actual mesh vertex bounding radii (equatorial vs. polar) for the Earth, cloud layer, and atmosphere shell and assert they match the WGS84 constants (equatorial 6,378,137 m, polar 6,356,752.314245 m, difference 21,384.685755 m) to within a small tolerance.

Added --no-atmosphere. Threaded a new flag through main.py -> scene.py (atmosphere_glow_enabled, defaults True) -> blender_scene.py. add_atmosphere is now split into add_space_background() (always applied -- the black deep-space World background) and add_atmosphere_glow() (the sun-facing limb-glow shell, now skippable). Rendered both ways to confirm the toggle actually works:

--no-atmosphere off (default)	--no-atmosphere on
bright glowing limb ring visible	hard Earth edge, no glow

Test/coverage status: 119 tests passing, 100% coverage maintained, ruff check/ruff format clean, ty check clean (no new errors).

[j4lando]

Removed the atmosphere/limb-glow shell entirely for now (add_atmosphere_glow, --no-atmosphere, atmosphere_glow_enabled, and its tests) rather than shipping it half-working behind a flag -- it's deprioritized, not gone for good; picking it back up later can start from the git history on blender_scene.py. render_scene() now just builds the WGS84-ellipsoid Earth + clouds, the Sun lamp, the black deep-space background, and the camera.

Here's a representative render from the current pipeline (--date 2026-03-20T12:00:00, ~25,000 km altitude, no atmosphere glow):

just check-all (ruff, 100% coverage, ty) and CI are both green on e02b831.