Add deployment: Dockerfile, compose, proxy config, and docs

One container plus a Postgres behind any TLS-terminating proxy. Nothing is
specific to a particular host.

The app and API are served from a SINGLE origin. This is not tidiness: browser
auth sessions live in per-origin storage, so splitting them across two
hostnames makes sign-in loop in a way that presents as a server fault. The
short alias redirects rather than serving a second origin.

Two safety properties verified by running the image, not by reading the code:

- With NODE_ENV=production and no SUPABASE_URL, the process refuses to start
  and says why. Serving the whole CRM unauthenticated is a worse outcome than
  failing to deploy, so the failure is deliberate and loud.
- In production the development auth bypass does not apply: an unauthenticated
  request to /api/dashboard returns 401 rather than adopting the first user in
  the table.

The Dockerfile typechecks all six packages as a build gate, so a deploy that
does not compile fails at build time rather than in front of a user. Runtime
runs unprivileged as `node`, and Postgres is not published to the host.

Docs cover the ontology and why it is shaped this way, agent connection for
Claude Code / Codex / prime-agent / Buzz, and the provenance rules governing
seed data about real people — including how to have your record removed.

Verified: image builds, container reports healthy, serves the SPA, enforces
auth, and the production guard exits non-zero.

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

docs/seed-data.md

@@ -0,0 +1,53 @@
+# Seed data and its provenance
+
+PIG ships with a roster of publicly documented people so the application is
+legible on first run. It is public research, not an assertion of fact.
+
+## Rules applied
+
+1. **Every record carries a confidence grade and a source URL.** `confirmed`
+   means two or more independent sources; `probable` means one good one;
+   `unverified` means a single weak or self-reported source. The grade is shown
+   in the interface wherever the record appears — a single-source claim about a
+   real person must never look as solid as a corroborated one.
+
+2. **No email addresses.** None are published by the subjects. Guessing them
+   from a name and a domain is unreliable, and when a guess lands it lands on a
+   real person who did not ask to be contacted.
+
+3. **Authorship is not employment.** People named on papers or in repositories
+   are recorded with the affiliation actually evidenced — `contributor`,
+   `resident`, `alumni` — never promoted to `staff` to make the roster look
+   fuller.
+
+4. **"Not found" is recorded, not invented.** Where a name was supplied but
+   could not be sourced, it appears in `UNRESOLVED_NAMES` with a note. Absence
+   is weak evidence: a junior or deliberately non-public employee looks
+   identical to a failed search.
+
+## Known limitations
+
+- Sourced August 2026. It will go stale — that is what `sourceUrl` is for.
+- LinkedIn, Glassdoor and several job boards refuse automated fetching, so some
+  records rest on search-result summaries rather than a page that was read
+  end to end. Those are graded accordingly.
+- One departure is recorded explicitly (a co-author who now lists a different
+  company) so the roster does not quietly imply current employment.
+- One name in the original brief could not be tied to the company by any source
+  and is deliberately **not** seeded.
+
+## Removing yourself
+
+If you are seeded here and would rather not be, open an issue and the record
+will be removed. Deleting a contact in the application also removes it
+permanently.
+
+## Turning it off
+
+Seeding is a separate command and is never automatic:
+
+```bash
+npm run db:seed     # opt in
+```
+
+Skip it and PIG starts empty apart from a development user.