feat(documents): surface filesystem work-products in Document Center

The Document Center only read the `documents` table, which is prose
content POSTed via /api/documents. Everything the agents wrote via
`bash` / `write` / `edit` — the bulk of their output on a real
project — landed in `work_products` and never appeared on the page.
Operators saw "0 items" after a full night's run.

Lift work_products into the same UI:

  - `listWorkProductsForCompany` returns a newest-first slice with a
    500-row cap so the snapshot stays bounded.
  - `ProfileSnapshot.workProducts` flows through `useCompanyData` as
    `companyWorkProducts`, filtered to the current company.
  - `DocumentCenter` renders two labelled sections in order — prose
    documents (editable) on top, files & deliverables below. Each
    work-product row opens the underlying URL or filesystem path
    when clickable, so the agent's bash-generated markdown, PRs,
    and artifacts are one click away.

`WorkProductRecord` lifts into `@shared/types/records-extended` so
the renderer, snapshot, and database shells all reference the same
shape. The store-test fixture learns about the new field.

tests/unit/store.test.ts

@@ -136,6 +136,7 @@ describe("useAppStore", () => {
       socialAccounts: [],
       meetings: [],
       documents: [],
+      workProducts: [],
       knowledgeBase: [],
       sprints: [],
       automationRules: [],
@@ -174,6 +175,7 @@ describe("useAppStore", () => {
       socialAccounts: [],
       meetings: [],
       documents: [],
+      workProducts: [],
       knowledgeBase: [],
       sprints: [],
       automationRules: [],
@@ -247,6 +249,7 @@ function makeSnapshot(overrides: Partial<ProfileSnapshot> = {}): ProfileSnapshot
     socialAccounts: [],
     meetings: [],
     documents: [],
+    workProducts: [],
     knowledgeBase: [],
     sprints: [],
     automationRules: [],