fix: unify OpenDART env var name with Gitea Secrets; add missed migration header notes

tools/ingest_fundamental_raw.py read DART_API_KEY, but the Gitea Secret
is registered as OPENDART_OPENAPI_KEY, and no workflow bridges the two
(none currently invoke this script). Renamed the code side to match
the secret name directly rather than adding a mapping layer, so
whenever this gets wired into a workflow it just works. Updated the
matching README setup instructions.

Also includes the V9/V10 migration header explanations (why they were
renamed from V003/V004) that were written earlier but missed from the
previous commit's file list.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

src/dotnet/QuantEngine.Infrastructure/Migrations/V10__Normalize_Snapshots_Schema.sql

@@ -1,8 +1,18 @@
--- Migration: V004_normalize_snapshots_schema.sql
+-- Migration: V10__Normalize_Snapshots_Schema.sql (renamed from
+-- V004_normalize_snapshots_schema.sql on 2026-07-30 — see note below)
 -- Purpose: Implement 3NF normalization for kis_collection_snapshots
 -- Phase: Phase 1 (Normalization & SOLID Refactoring)
 -- Status: APPROVED for Sep 2026 implementation
 -- Safety: Parallel operation with existing schema via Adapter pattern
+--
+-- 2026-07-30: Originally named V004_normalize_snapshots_schema.sql, which alphabetically
+-- sorted BEFORE V1__Initial_Schema.sql. Its FK constraint referencing
+-- quantengine.kis_collection_runs(id) (created by V2) is not guarded — on a fresh database
+-- this would hard-fail with "relation does not exist" and abort every migration after it,
+-- meaning V1 through V8 would never run at all. Renamed to V10 (after DbMigrator.cs was given
+-- a numeric-aware script comparer, MigrationScriptNameComparer, so double-digit versions sort
+-- correctly) so it now runs after its dependency exists. Confirmed via production query that
+-- this migration had never actually applied.
 
 -- ============================================================================
 -- DIMENSION TABLES (Star Schema)