WIP durable state models

[nonprofittechy]

Summary

Adds a durable filing-draft foundation for the LITEFile workflow while preserving the existing session-backed behavior for incremental migration and review.

Key changes:

• Introduces durable source-of-truth models:
  • FilingDraft for one filing workflow instance, including jurisdiction, status, current step, case classification, existing-case identifiers, selected payment account, extracted guesses, optional services, extra case data, and submission response.
  • FilingDocument for lead/supporting uploaded documents, including S3/public URL metadata, file metadata, Tyler filing/document/component codes, courtesy copy email, and document order.
  • FilingParty for people or organizations associated with a draft, including role, party type, contact fields, name fields, address fields, and metadata.
• Adds Django admin support for the new filing draft, document, and party models.
• Adds request-independent draft service helpers in services/drafts.py.
• Adds services/current_drafts.py to resolve the current browser's draft while validating authenticated ownership, active status, and jurisdiction. The session stores only the current durable draft ID.
• Adds services/legacy_draft_bridge.py as a temporary compatibility adapter that mirrors legacy case_data and upload_data session blobs into durable draft/document/party records.
• Adds a durable draft creation route at POST /jurisdiction/<jurisdiction>/drafts/ and a current-draft API at GET /api/draft/.
• Updates the options/start flow to create a durable draft and redirect to the first upload step, while falling back to the legacy session start path if draft creation fails.
• Updates legacy case-data and upload-data save endpoints to shadow-write into the current durable draft so the old UI can continue working during migration.
• Adds get_workflow_step_choices() so the model's current_step choices stay derived from the workflow registry.
• Adds documentation in docs/filing-draft-data-model.md describing the model boundaries, compatibility bridge, rollout expectations, and follow-up migration sequence.
• Adds tests for model/service normalization, document sync, draft snapshots, draft creation, current-draft ownership/jurisdiction protection, legacy endpoint mirroring, workflow-step choices, partial case updates, and complete upload replacement behavior.

Behavior and compatibility notes

• This PR is intended as a foundation, not a full cutover from session state.
• Existing session-backed behavior remains in place for incremental review.
• The durable draft path requires an authenticated user and validates ownership on each current-draft lookup.
• Jurisdiction is checked when resolving a current draft so a browser/session cannot accidentally resume a draft from another jurisdiction.
• extra_case_data, document metadata, and party metadata are intentionally kept as temporary escape hatches while the UI moves from arbitrary session blobs to typed draft updates.
• Legacy session save endpoints continue to save session data, then mirror known fields into the durable models when a current draft exists.

Migration and deploy notes

• The efile app previously had no migrations even though existing environments may already have the UserProfile table.
• 0001_initial.py therefore baselines the existing UserProfile model.
• 0002_filing_drafts.py creates the new FilingDraft, FilingDocument, and FilingParty tables, indexes, and ordering constraints.
• The Fly release command now runs migrate --noinput --fake-initial so existing deployments can fake the baseline migration while fresh databases still apply both migrations normally.

Intended follow-up migration sequence

1. Replace legacy case-data endpoints with typed draft updates.
2. Replace legacy upload endpoints with typed document updates.
3. Move payment selection into explicit draft fields.
4. Render review from FilingDraft, FilingDocument, and FilingParty.
5. Move final submission to a draft-backed submission service.
6. Remove legacy_draft_bridge.py, arbitrary session-merge APIs, and browser storage persistence.

Open question

@BryceStevenWilley this is still a rough starting point for discussing migration to a clearer data model and draft system. Do we need backwards compatibility with the existing draft/session system, or are we free to fully discard it? If we can discard it, a fair amount of the compatibility bridge and fallback code here can be removed.