Parse transferable days from FK instead of deriving them

The scraper never read "överlåtbara dagar" from Försäkringskassan. It only
visited ansok-och-planera-foraldrapenning#/valjdagar and derived the
reserved/transferable split in build_snapshot, assuming transferable days
are spent before reserved ones. On real data that gave 49 for the user and
0 for the partner where FK states 129 and 71.

The assumption cannot be repaired: reserved-first, transferable-first,
proportional and cap-based models were all checked against real figures and
none reproduces FK's accounting (reserved-first fits the partner but is 10
days off for the user). FK publishes the real numbers per parent per tier on
the min-foraldrapenning page, which the scraper had never visited.

- Scrape the "Dagar ni kan föra över" panel after the valjdagar extraction,
  summing sjukpenningnivå + lägstanivå per parent. The totals are not
  literals on the page. Parse only direct-child <p> elements: the first
  group embeds a tooltip with decoy "45 dagar"/"90 dagar" text.
- build_snapshot accepts the reported value and derives reserved days from
  it; the old arithmetic remains only as a fallback. An implausible FK value
  degrades to that fallback rather than failing the fetch.
- Record provenance in transferable_days_reported (migration 006) and badge
  derived values as estimates in the dashboard breakdown. Drop the footnote's
  claim that at most 150 days are transferable — real data contradicts it as
  a per-family figure.
- Select the child's section by name when FK lists several; never guess.

Verified against a live BankID scrape: scraped 240/101/139 with 129
transferable, deduced partner 240/169/71 with 71, both flagged as reported.

Incidental fixes found along the way:

- The fetch router never forwarded the partner's transferable figure to
  persist_partner_deduction, so the partner's stored snapshot would have kept
  the flawed split even once the parse landed.
- 'deduced' snapshots were labelled "Manually entered" by a two-way ternary
  over a three-value union. Replaced with a compiler-checked exhaustive map.
- Alembic resolved its database from alembic.ini alone, ignoring
  APP_SQLITE_PATH, so migrations silently targeted the developer's real
  database even when pointed elsewhere. env.py now resolves it, preferring
  -x sqlalchemy.url, then a real APP_SQLITE_PATH, then the ini value.
- backend/captures/ was not ignored: the root pattern was anchored as
  /captures/ despite a comment saying scraper dumps must never be tracked.
- CLAUDE.md quoted test counts and coverage percentages that had gone stale,
  which made a correct verification report look suspect. Gate thresholds kept.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DXPBfr1v7F71t6QcbHCaaT

backend/app/services/fetch_data_service.py

@@ -118,6 +118,7 @@ async def persist_partner_deduction(
     sjukpenning_left: int,
     lagsta_niva_left: int,
     dubbeldagar_left: int,
+    transferable_days_left: int | None = None,
 ) -> None:
     """Persist a 'deduced' snapshot for the caller's partner, if there is one.
 
@@ -126,7 +127,10 @@ async def persist_partner_deduction(
     `app.scrapers.fk_scraper._deduce_partner`). Takes plain fields rather
     than the scraper's `PartnerDeduction` dataclass to avoid a router/scraper
     import cycle (`fk_scraper` already imports from this module) — the
-    router unpacks it before calling in.
+    router unpacks it before calling in. `transferable_days_left`, when
+    known (FK's own reported figure for the partner), is forwarded to
+    `build_snapshot` so the partner's reserved/transferable split doesn't
+    fall back to the transferable-first assumption either.
 
     A no-op (logged, never raised) unless the workspace has exactly one
     other non-deleted member: with zero, there's no one to persist for; with
@@ -155,6 +159,7 @@ async def persist_partner_deduction(
             sjukpenning_left=sjukpenning_left,
             lagsta_niva_left=lagsta_niva_left,
             dubbeldagar_left=dubbeldagar_left,
+            transferable_days_left=transferable_days_left,
         )
         await parental_leave_repo.create(fetch)
     except Exception as exc:

backend/app/services/leave_snapshot.py

@@ -9,6 +9,13 @@ itself — see PLANNING_ENGINE_SPEC.md and the "Bug A" note in
 `app.utils.tip_predicates.default_tier_pool_share` for what happens when two
 call sites disagree.
 
+FK's `min-foraldrapenning` e-service page does report the
+reserved/transferable split directly, in its "Dagar ni kan föra över" panel
+— when a caller has that figure (a scraper parse, or a detailed manual
+entry) it should be passed as `transferable_days_left`. The
+"transferable-first" arithmetic below is only a fallback for when that
+figure isn't available.
+
 Domain: a child has `rules.total_days_per_child` days total (390
 sjukpenningnivå + 90 lägstanivå). Split across two parents each gets half
 (195 + 45 = 240); `rules.reserved_days_per_parent` (90) of each parent's
@@ -40,16 +47,29 @@ def build_snapshot(
     lagsta_niva_left: int,
     dubbeldagar_left: int,
     reserved_days_left: int | None = None,
+    transferable_days_left: int | None = None,
     fetched_at: datetime | None = None,
 ) -> ParentalLeaveFetch:
     """Derive and validate a full `ParentalLeaveFetch` snapshot.
 
-    `reserved_days_left`, when omitted, is derived assuming transferable
-    (non-reserved) days are always consumed before reserved ones — the same
-    assumption the FK scraper's page reading has always made, since FK's UI
-    doesn't expose the reserved/transferable split directly. When the caller
-    already knows the reserved split (e.g. a future, more detailed manual
-    form), passing it directly skips that assumption.
+    `reserved_days_left` and `transferable_days_left` are mutually
+    exclusive — passing both raises `ValidationError`, since each one alone
+    fully determines the other (`transferable_days_left = days_left -
+    reserved_days_left`).
+
+    `transferable_days_left` is FK's own reported figure, read off the
+    "Dagar ni kan föra över" panel on the `min-foraldrapenning` e-service
+    page. When it is supplied, `reserved_days_left` is computed from it
+    (`days_left - transferable_days_left`) and checked by the same
+    validators below as any other value.
+
+    When neither is supplied, `reserved_days_left` falls back to an
+    assumption — transferable (non-reserved) days are always consumed
+    before reserved ones — used only because FK's own figure wasn't
+    available (manual entry with no split known, or a failed parse of that
+    panel). When the caller already knows the reserved split directly
+    (e.g. a future, more detailed manual form), passing `reserved_days_left`
+    skips that assumption.
     """
     if source not in _VALID_SOURCES:
         raise ValidationError(
@@ -57,6 +77,17 @@ def build_snapshot(
             message_key="parentalLeave.invalidSource",
             data={"source": source},
         )
+    if reserved_days_left is not None and transferable_days_left is not None:
+        raise ValidationError(
+            "reserved_days_left and transferable_days_left are mutually exclusive "
+            "— each one alone determines the other",
+            message_key="parentalLeave.conflictingTransferableOverride",
+            data={
+                "reserved_days_left": reserved_days_left,
+                "transferable_days_left": transferable_days_left,
+            },
+        )
+    transferable_days_reported = transferable_days_left is not None
 
     rules = settings.rules
 
@@ -75,18 +106,22 @@ def build_snapshot(
     lagsta_niva_used = lagsta_niva_total - lagsta_niva_left
 
     # -- Reserved / transferable split --
-    # Reserved days cannot be transferred to the other parent; the
-    # long-standing assumption (matches FK's own "spend transferable first")
-    # is that transferable days are used up before any reserved day is.
+    # Reserved days cannot be transferred to the other parent. FK reports
+    # the transferable figure directly (see docstring); when it isn't
+    # available, fall back to the long-standing assumption (matches FK's
+    # own "spend transferable first") that transferable days are used up
+    # before any reserved day is.
     reserved_days_total = rules.reserved_days_per_parent
-    if reserved_days_left is None:
+    if transferable_days_left is not None:
+        reserved_days_left = days_left - transferable_days_left
+    elif reserved_days_left is not None:
+        transferable_days_left = days_left - reserved_days_left
+    else:
         transferable_total = total_days - reserved_days_total
         transferable_used = min(days_used, transferable_total)
         reserved_used = days_used - transferable_used
         reserved_days_left = reserved_days_total - reserved_used
         transferable_days_left = transferable_total - transferable_used
-    else:
-        transferable_days_left = days_left - reserved_days_left
 
     # -- Validate before returning --
     if days_left < 0:
@@ -180,6 +215,7 @@ def build_snapshot(
         reserved_days_total=reserved_days_total,
         reserved_days_left=reserved_days_left,
         transferable_days_left=transferable_days_left,
+        transferable_days_reported=transferable_days_reported,
         dubbeldagar_left=dubbeldagar_left,
         tier_data=tier_data,
         created_at=now,