Split administrative-correction into typed development/remission corrections

Resolves the WP-0003-T06 review flag: the single administrative-correction
ledger entry type had an unstated fold-side effect (concept §17 names the
type but never says which side of the target it corrects). Maintainer chose
option (a) — split into administrative-correction-development and
administrative-correction-remission so the corrected side is explicit in
the type name rather than an implicit library default.

- schemas/ledger_entry.schema.json: enum split, no other behavior change.
- src/target_revenue/fold.py: each new type maps to its named side only.
- specs/TargetLedgerSpecification.md, TechnicalSpecificationDocument.md
  §3.2, ProductRequirementsDocument.md FR-5: updated to the split types.
- tests/test_ledger_fold.py: dedicated coverage for both new types plus a
  regression test that the old unsplit type name is now rejected.

spec/TargetRevenueLicenseConcept.md §17 is left unedited — its entry-type
list is explicitly non-exhaustive ("may include"), so this specializes
rather than contradicts it.

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

schemas/ledger_entry.schema.json

@@ -32,10 +32,11 @@
         "remission-credit",
         "credit-reversal",
         "remission-correction",
-        "administrative-correction",
+        "administrative-correction-development",
+        "administrative-correction-remission",
         "conversion-checkpoint"
       ],
-      "description": "Closed set per TSD §3.2; not extensible per-project."
+      "description": "Closed set per TSD §3.2; not extensible per-project. administrative-correction-development/-remission split 2026-07-29 to make the corrected target side explicit in the type name (specs/TargetLedgerSpecification.md §2)."
     },
     "amount": {
       "type": "number",