Migration: Folder structure

Migrate this Attio app from the legacy `app.ts` registration layout to the folder-based layout,
by hand. The automatic migrator (`attio migrate folder-structure`) refused this app. Read its
blockers first: each names the file and symbol that needs attention. Fix what it flagged, and
make the equivalent moves manually.

Start from a clean, committed working tree so every change is reviewable with `git diff`.

Target layout

- Every extension registered in `app.ts` (`record.actions`, `record.bulkActions`,
  `record.widgets`, `object.actions`, `callRecording.{insight,summary,transcript}.textActions`)
  becomes its own folder, `src/app/extensions/<id>/extension.tsx`, default-exporting the same
  configuration wrapped in the factory:

    import {Extensions} from "attio/client"

    export default Extensions.defineExtension({
        type: "record-action", // or: bulk-record-action | record-widget | object-action |
                               // call-recording-{insight,summary,transcript}-text-action
        // ...the original configuration object, unchanged
    })

  Sibling files in the folder are private helpers; only `extension.tsx` is discovered. The
  folder name is cosmetic; the id in the call is what matters.

- Legacy settings (`src/app.settings.ts` plus the Page under `settings.workspace`) migrate as
  one unit, never partially:
  - `src/app/settings/schema.ts`: `export default Settings.defineWorkspaceSchema({...})`
    using `Settings.Schema.string()/number()/boolean()`, with `import {Settings} from "attio"`.
  - `src/app/settings/page.tsx`: `export default Settings.defineWorkspacePage(schema, () => ...)`,
    a zero-argument callback, with `import schema from "./schema"` and
    `import {Settings} from "attio/client"`.
  - Inside the page component only, rewrite the calls:
    `useWorkspaceSettingsForm()` -> `Settings.useForm(schema)`
    `useWorkspaceSettings()` -> `Settings.useSettings(schema)`
    `getWorkspaceSettings()` -> `Settings.getSettings(schema)`
    `getWorkspaceSetting(key)` -> `Settings.getSettings(schema, key)`
    `setWorkspaceSetting(key, value)` -> `Settings.setSettings(schema, key, value)`

- `src/events/**` moves to `src/app/events/**` and `src/webhooks/**` to `src/app/webhooks/**`,
  contents unchanged, relative imports fixed. Keep the same filenames.

- `src/blocks/**` moves to `src/app/blocks/**`, each block folder as-is, relative imports
  fixed. Keep the same folder names.

Rules that keep the migration safe

1. Never change an extension id, a block id, or an event/webhook filename; these are dispatch
   identity in production.
2. Move code, do not rewrite it: function bodies, JSX, and server helpers stay logically
   identical.
3. Moving an extension turns its named export into a default export. Update every importer:
   named imports become default imports; re-exports become `export {default as name} from ...`.
4. Settings calls outside the settings page (shared hooks, helpers, server functions) stay on
   the legacy API. Do not do a global find-and-replace.
5. Workflow block folders move but their contents are never edited.
6. Remove each migrated registration, and any imports it leaves unused, from `app.ts`. Delete
   `app.ts` only when nothing meaningful remains AND you created files under `src/app/`.

Verify

- `attio build` passes and TypeScript is clean.
- `attio migrate folder-structure --dry-run` now reports nothing left to migrate.
- `git diff` shows file moves plus the factory wrappers and import updates, and nothing else.
  Anything the migration did not need to touch should be byte-identical.
- Run `attio dev` and confirm every extension, settings page, block, and handler still shows
  up and works.