Side-by-Side PDF Viewer on Document Details, Plus Containerized Build Pipeline

This QA release reworks the Document Details experience so the document and its file preview sit side by side in a resizable split view, and it ships the build/deploy plumbing (Docker image + ECR push workflow) for the frontend. It bundles feature work from PRs #332 (resizable PDF viewer) and #336 (API URL hardening and an upload-center fix tied to the Filestack removal).

On the previous Document Details and Document Metadata screens the PDF preview was embedded as a fixed inner column, so users could not adjust how much space the document data versus the file preview received, and the layout was duplicated inside several components. Reviewers wanted the file visible alongside details, metadata, and resolution work without losing room for the data they were editing.

When viewing a document (both standalone documents and batch documents) and in the Mail Resolution Documents tab, users now see the file preview in a resizable panel next to the content. They can drag the divider to rebalance the two panes, double-click it to reset to the default split, and the chosen layout is remembered across visits. The preview auto-shows on the Details and Metadata tabs and hides on Activity and Resolution to give those tabs full width. A Download button opens the file in a new tab. No change to which documents or fields a user can access.

• New split-panel layout using react-resizable-panels (PanelGroup/Panel/PanelResizeHandle) on documents/[id]/page.tsx and batches/documents/[id]/page.tsx, plus the Mail Resolution DocumentsTab; panel sizes persisted to localStorage and a double-click handler resets the split.
• PDF preview lifted to the page level: removed the embedded PDFViewer and its surrounding card from document-details.tsx and document-metadata.tsx; tab content switched to forceMount + hidden so panes keep state, with PDF visibility driven by the active tab.
• API base URL hardening in src/http/api.ts: reads NEXT_PUBLIC_API_URL into a constant, logs an error if unset, and falls back to a hardcoded dev backend URL.
• mail.services.ts: upload_center_id is now only added to the update payload when the center value is a non-empty string (previously only checked for null/undefined).
• Build/CI: new multi-stage Dockerfile (Next.js, port 3000) and a GitHub Actions workflow that builds and pushes images to ECR for the dev and main branches; minor .gitignore edit (stops ignoring .github).

Mostly UI and infrastructure risk. The layout rewrite changes how the Details/Metadata/Resolution panes render (absolute-positioned, force-mounted tabs), so visual or scroll regressions are the main concern. The api.ts change adds a hardcoded dev backend fallback URL: if NEXT_PUBLIC_API_URL is missing in any environment, the app would silently point at the dev backend rather than failing loudly. Mitigation: verify the env var is set in the QA/Production deploy configs so the fallback never triggers. The Docker/ECR workflow is build-time only and does not affect runtime behavior. Console logging of the update payload remains in mail.services.ts.

• On Document Details (standalone, batch, and Mail Resolution Documents tab): confirm the PDF preview appears beside the content, drag the divider to resize, double-click to reset, and reload to confirm the layout persists.
• Switch tabs: preview should show on Details/Metadata and hide on Activity/Resolution, giving those tabs full width; confirm tab content scrolls correctly.
• Verify the file loads in the preview and the Download button opens it in a new tab.
• Confirm the metadata screen no longer shows a second/duplicate preview card.
• Confirm NEXT_PUBLIC_API_URL is configured in QA so API calls hit the QA backend (not the dev fallback).
• Edit a document's mail details with and without an upload center selected; confirm the update saves correctly and an empty center is not sent.