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>

specs/TargetLedgerSpecification.md

@@ -19,9 +19,12 @@ The Target Ledger is the append-only record of everything that moves a Phase's O
 | `remission-credit` | `+= amount` to Remission Credit | Rule 5: never represented as revenue. |
 | `credit-reversal` | `-= amount` from Development Credit | Rule 8: compensating entry; requires `reverses` pointing to the original entry id. Never edits or deletes the original. |
 | `remission-correction` | `+= amount` to Remission Credit (amount may be negative) | Requires `reverses`. |
-| `administrative-correction` | `+= amount` to Development Credit | **Stage 0 simplification:** a generic correction bucket, not yet specialized by which side of the target it corrects. Revisit if this proves ambiguous in practice. |
+| `administrative-correction-development` | `+= amount` to Development Credit | Generic correction on the development side, not tied to a specific prior credit entry. |
+| `administrative-correction-remission` | `+= amount` to Remission Credit | Generic correction on the remission side, not tied to a specific prior remission entry. |
 | `conversion-checkpoint` | No numeric effect | Marker only. |
 
+**Resolved 2026-07-29:** the concept document (§17) lists a single, non-exhaustive `administrative-correction` entry type ("permitted entry types **may include**...") without specifying which side of the target it adjusts. This extract specializes it into the two typed entries above, closing that ambiguity in the type name itself rather than leaving it as an unstated fold-side default. This does not contradict the concept document — its list was illustrative, not a closed enum — but it is a Stage 0 interpretation this extract adds beyond direct citation, so it remains listed for `workplans/TREV-WP-0003-normative-core-extraction.md` T06 review alongside the rest of this file.
+
 This set is closed for Stage 0: a project **must not** invent new entry types; new monetization behavior belongs in an extension (`specs/MonetizationExtensionSpecification.md`), not a new ledger entry type.
 
 ## 3. Required entry fields
@@ -53,8 +56,8 @@ Per Rule 8, the ledger is append-only. A correction or reversal is always a **ne
 ## 6. Outstanding Target fold (normative definition)
 
 ```text
-Outstanding Target = max(0, Initial Target − Σ(development-credit, administrative-correction)
-                                            − Σ(remission-credit, remission-correction)
+Outstanding Target = max(0, Initial Target − Σ(development-credit, administrative-correction-development)
+                                            − Σ(remission-credit, remission-correction, administrative-correction-remission)
                                             + Σ(credit-reversal))
 ```