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>

workplans/TREV-WP-0003-normative-core-extraction.md

@@ -94,11 +94,21 @@ state_hub_task_id: "ab11ec85-9c4c-4ca1-bc58-a0a044241c01"
 
 Result 2026-07-29: `specs/TargetLedgerSpecification.md` (TRF-Ledger-0.1)
 produced, aligned with `schemas/ledger_entry.schema.json` and
-`src/target_revenue/fold.py`/`hashing.py`. Flags the
+`src/target_revenue/fold.py`/`hashing.py`. Flagged the
 `administrative-correction` fold-side effect as a Stage 0 simplification
 (concept §17 names the entry type but does not specify which side of the
-target it corrects) — called out explicitly for T06 review rather than
-presented as settled.
+target it corrects) for T06 review.
+
+Result 2026-07-29 (same day, human decision): **Resolved** — maintainer
+chose to split the ambiguous type into `administrative-correction-development`
+and `administrative-correction-remission` (option (a) of three offered).
+Updated `schemas/ledger_entry.schema.json`, `src/target_revenue/fold.py`,
+`specs/TargetLedgerSpecification.md` §2/§6, `specs/TechnicalSpecificationDocument.md`
+§3.2, and `specs/ProductRequirementsDocument.md` FR-5. Added dedicated test
+coverage (`tests/test_ledger_fold.py`) for both new types plus a regression
+test confirming the old unsplit type name is now rejected. `spec/TargetRevenueLicenseConcept.md`
+§17 was left unedited — its entry-type list is explicitly non-exhaustive
+("may include"), so the split specializes rather than contradicts it.
 
 Produce `specs/TargetLedgerSpecification.md` from concept §17 and TSD §3.2:
 
@@ -182,12 +192,12 @@ accept):
       `schemas/phase_manifest.schema.json` (already implemented, WP-0002-T02);
       `phase.longstop_at` is explicitly labeled a Stage 0 working default
       (Q8), not silently presented as permanent Rule 1 scope.
-- [ ] `specs/TargetLedgerSpecification.md` — entry-type table matches
-      `schemas/ledger_entry.schema.json`; the `administrative-correction`
-      "Stage 0 simplification" note in §2 is flagged for maintainer judgment
-      — this is the one place this extraction added interpretation beyond a
-      direct concept citation (concept §17 lists the entry type but does not
-      specify its fold-side effect).
+- [x] `specs/TargetLedgerSpecification.md` — entry-type table matches
+      `schemas/ledger_entry.schema.json`. **Resolved 2026-07-29:** the
+      `administrative-correction` ambiguity was reviewed and split into
+      `administrative-correction-development` / `-remission` (maintainer's
+      choice of option (a)); this was the one place the extraction added
+      interpretation beyond a direct concept citation, and it is now closed.
 - [ ] `specs/MonetizationExtensionSpecification.md` — six-field contract
       matches concept §12; registered/canonical distinction matches concept
       §12.1–§12.2; Stage 0 catalog table (Q11) correctly shows