feat(proceeding-type): explicit ערר/בל"מ field for cases + corpus

Same case_number can exist as both a regular appeal (ערר) and an
extension-of-time request (בל"מ), and we were inferring the difference
from appeal_subtype prefixes — fragile, and case-number lookups
weren't disambiguated. Now stored as a first-class field on both
case_law (corpus) and cases (live cases), with partial unique indexes
on (case_number, proceeding_type).

- SCHEMA_V15: column + CHECK constraints + backfill from
  appeal_subtype LIKE 'extension_request_%' + partial unique indexes
  replace the old global UNIQUE(case_number).
- derive_proceeding_type() centralizes the inference rule
  (extension_request_* → בל"מ; subject regex fallback; default ערר).
- Metadata extractor prompt asks Claude to populate the new field
  explicitly; apply_to_record writes it for internal_committee rows.
- internal_decision_upload, case_create, case_update accept an
  optional proceeding_type; FastAPI request models expose it.
- Wizard + edit dialog get a sided Select; case header renders the
  resolved label (ערר / בל"מ).
- Uploaded the 2 staged בל"מ decisions on betterment levy:
  8126/24 (סופר נוח, 13 chunks), 8047/23 (הרנון, 48 chunks).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

web-ui/src/components/cases/case-header.tsx

@@ -41,7 +41,7 @@ export function CaseHeader({ data }: { data?: CaseDetail }) {
           <div className="space-y-2">
             <div className="flex items-center gap-3 flex-wrap">
               <span className="font-display text-[2rem] font-black text-navy leading-none tabular-nums">
-                ערר {data?.case_number ?? "—"}
+                {data?.proceeding_type ?? "ערר"} {data?.case_number ?? "—"}
               </span>
               {data?.status && <StatusBadge status={data.status} />}
               {data?.archived_at && (