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/repositories_impl/sqlite/parental_leave_repository.py

@@ -45,6 +45,7 @@ class SQLiteParentalLeaveRepository(ParentalLeaveRepository):
             tier_data=tier_data,
             created_at=datetime.fromisoformat(row["created_at"]),
             updated_at=datetime.fromisoformat(row["updated_at"]),
+            transferable_days_reported=bool(row["transferable_days_reported"]),
         )
 
     @staticmethod
@@ -69,8 +70,9 @@ class SQLiteParentalLeaveRepository(ParentalLeaveRepository):
             INSERT INTO parental_leave_fetch
                 (id, personal_data_uuid, workspace_id, child_id, source, fetched_at,
                  total_days, days_used, days_left, reserved_days_total, reserved_days_left,
-                 transferable_days_left, dubbeldagar_left, tier_data, created_at, updated_at)
-            VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
+                 transferable_days_left, dubbeldagar_left, tier_data, created_at, updated_at,
+                 transferable_days_reported)
+            VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
             """,
             (
                 str(item.id),
@@ -89,6 +91,7 @@ class SQLiteParentalLeaveRepository(ParentalLeaveRepository):
                 self._tier_data_to_json(item.tier_data),
                 item.created_at.isoformat(),
                 item.updated_at.isoformat(),
+                int(item.transferable_days_reported),
             ),
         )
         await commit(self._conn)
@@ -137,7 +140,7 @@ class SQLiteParentalLeaveRepository(ParentalLeaveRepository):
             UPDATE parental_leave_fetch
                SET days_used = ?, days_left = ?, reserved_days_left = ?,
                    transferable_days_left = ?, dubbeldagar_left = ?,
-                   tier_data = ?, updated_at = ?
+                   tier_data = ?, updated_at = ?, transferable_days_reported = ?
              WHERE id = ?
             """,
             (
@@ -148,6 +151,7 @@ class SQLiteParentalLeaveRepository(ParentalLeaveRepository):
                 item.dubbeldagar_left,
                 self._tier_data_to_json(item.tier_data),
                 item.updated_at.isoformat(),
+                int(item.transferable_days_reported),
                 str(id),
             ),
         )