refactor(scoring): name formula constants and type env vars

[Gbemi-programmer]

Summary

Closes #230
Closes #232
Closes #231
Closes #229

#230 — Magic numbers → named constants

computeScores no longer hardcodes 50/100. Constants live at the top of
src/lib/scoring.ts, each with a comment explaining its role:

Constant	Value	Meaning
SCORE_MIN / SCORE_MAX	0 / 100	bounds of any impact score
PERCENT_MAX	100	upper bound of a percentage input
GREEN_IMPACT_POWER_WEIGHT	50	points contributed by power utilisation
GREEN_IMPACT_FOREST_WEIGHT	50	points contributed by forest density
POWER_RATIO_FALLBACK	0	ratio used when max_power_kw is 0

Arithmetic is unchanged — every existing assertion still passes, plus a new
test that recomputes the expected score from the constants themselves.

#232 — Timestamps on IotInput

solar.timestamp and satellite.timestamp are now declared, optional, so the
values getSolarData/getSatelliteData already return are no longer dropped at
the type boundary. computeScores deliberately ignores them — scoring stays a
pure function of the reading's values — and that is documented on the fields so
a future staleness check has an obvious place to hook in. Optional means no
existing caller changes.

#231 — ndvi_score: documented, not removed

The field is not dead. computeScores scores greenery from
forest_density_pct alone, but computeScoresWithFormula
(src/lib/scoring-formula.ts:101) weights ndvi_score through ndvi_weight,
and /api/scoring-formulas exercises that path. Removing it from IotInput
would break the configurable formula engine and every route that forwards
satellite data. So the decision is documented in a JSDoc block on the field
rather than the field being dropped.

#229 — Typed environment variables

New src/types/env.d.ts merges into NodeJS.ProcessEnv and declares every
variable the codebase reads — Stellar/Soroban, HTTP, database, resilience, cron
and IoT, rate limiting, logging and APM — each documented with its expected
format and default. All are string | undefined, matching reality: the process
environment is untyped strings and any variable may be absent, so callers still
parse and default. The doc block points readers at src/config.ts as the
preferred access path; this declaration makes the remaining direct
process.env reads safe and autocompleting.

Note on one unrelated line

src/__tests__/scoring.test.ts had a stray extra }); on main that made the
whole suite fail to parse — no test in the file was running. I removed that
single brace so the tests here can execute; nothing else in the existing tests
was touched.

Verification

• npx jest src/__tests__/scoring.test.ts — 26 passed
• npx tsc --noEmit — clean
• npx eslint + npx prettier --check on changed files — clean

[drips-wave]

@Gbemi-programmer Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits