feat(FN-3544): add project-scoped auth storage and docs updates

- Add project auth storage model and persistence wiring in core DB/store/types
- Expand core test coverage for DB migration, store behavior, and project auth store flows
- Update heartbeat agent, settings, dashboard, and storage documentation for the new behavior
- Replace hardcoded mobile touch-target sizing in dependency graph styles with token-based sizing

Fusion-Task-Id: FN-3544

docs/agents.md

@@ -237,6 +237,7 @@ The `runtimeConfig` field on agents supports the following options:
 | `autoClaimRelevantTasks` | `boolean` | `true` | During no-task heartbeats, opportunistically claim unowned relevant todo tasks that align with the agent's role/soul |
 | `heartbeatTimeoutMs` | `number` | — | Time without heartbeat before agent is considered unresponsive (ms) |
 | `maxConcurrentRuns` | `number` | `1` | Max concurrent heartbeat runs for this agent |
+| `runMissedHeartbeatOnStartup` | `boolean` | `false` | When enabled, if the server was down across this agent's scheduled heartbeat tick, fire one catch-up heartbeat at startup (only when `lastHeartbeatAt` is older than the resolved interval) |
 | `allowParallelExecution` | `boolean` | `true` (when unset) | Permanent agents only. When `false`, heartbeat and executor paths serialize symmetrically: a heartbeat will not start while the agent's bound task has an active executor session, and an executor session will not start while the agent has an active heartbeat run |
 | `messageResponseMode` | `"immediate" \| "on-heartbeat"` | `"immediate"` | Whether agent wakes immediately on message (immediate) or processes during heartbeat (on-heartbeat). See [Heartbeat Run Mailbox Checking](#heartbeat-run-mailbox-checking) |
 | `selfImproveEnabled` | `boolean` | `true` | Enable periodic self-improvement reflection prompts during heartbeat runs |
@@ -249,7 +250,9 @@ The `runtimeConfig` field on agents supports the following options:
 Heartbeat values are validated and minimum-clamped to 5 minutes (300,000 ms).
 Project setting `heartbeatMultiplier` (default `1`) scales resolved heartbeat intervals globally; per-agent `heartbeatIntervalMs` remains the base interval before multiplier scaling. This setting is configured from the **Agents** screen's **Controls** popup under "Heartbeat Speed".
 
-`allowParallelExecution` defaults to `true` when unset; setting it to `false` is serialized explicitly so operators can enforce non-parallel heartbeat/executor behavior for that permanent agent.
+`runMissedHeartbeatOnStartup` defaults to `false` and is configured in **Agent Detail → Settings → Heartbeat Settings → Run Missed Heartbeat On Startup**.
+
+`allowParallelExecution` defaults to `true` when unset; setting it to `false` is serialized explicitly so operators can enforce non-parallel heartbeat/executor behavior for that permanent agent. Configure it in **Agent Detail → Settings → Heartbeat Settings → Allow Parallel Execution**.
 
 ### No-task auto-claim behavior
 
@@ -549,6 +552,19 @@ Expected behavior for both manual and automatic triggers:
 
 Messages remain an important input signal, but they do not replace the heartbeat procedure.
 
+### Heartbeat/Executor Separation (Current Behavior)
+
+For permanent agents, heartbeat runs now continue as an ambient coordination loop even when the currently bound task is blocked from normal task progress.
+
+- **Heartbeat path**: coordination, wake processing, mailbox/delegation/memory/task-creation actions, and lightweight ambient follow-through.
+- **Executor path**: task-body implementation work from task steps/prompts.
+
+When `allowParallelExecution` is set to `false` on a permanent agent, the two paths serialize symmetrically:
+- Heartbeat does not start while the bound task has an active executor session.
+- Executor does not start while the agent has an active heartbeat run.
+
+When `allowParallelExecution` is `true` (default), both paths may run concurrently.
+
 ## Heartbeat Run Mailbox Checking
 
 When messaging tools are enabled for an agent, heartbeat runs check for unread mailbox messages during execution regardless of the trigger type. This ensures agents can see and respond to incoming messages without needing an explicit wake-on-message trigger.

docs/dashboard-guide.md

@@ -288,6 +288,8 @@ The **Logs** tab includes an **Agent Log** subview designed for debugging long-r
 - The initial load fetches a recent page, then **Load More** progressively prepends older history.
 - Live streaming appends new entries in chronological order while preserving your scroll position when loading older pages.
 - The **Markdown / Plain** toggle lets you switch between formatted markdown and literal/raw text rendering.
+- The **Tools: On/Off** toggle shows or hides tool-call rows (`tool`, `tool_result`, `tool_error`) so you can focus on narrative/thinking output when needed.
+- Both display preferences persist across sessions via local storage (`fn-agent-log-markdown` and `fn-agent-log-tool-output`).
 
 The **Routing** tab shows:
 - effective node

docs/settings-reference.md

@@ -556,6 +556,8 @@ fn plugin install ./plugins/fusion-plugin-openclaw-runtime
 ```
 
 > 💡 In the dashboard, go to **Settings → Plugins → Fusion Plugins**. The **Bundled Plugins** section surfaces Agent Browser, Hermes, Paperclip, OpenClaw, Droid, and Dependency Graph directly from shipped manifests, shows install status, and provides one-click install actions for plugins that are not yet installed.
+>
+> ℹ️ Bundled runtime plugins (`fusion-plugin-paperclip-runtime`, `fusion-plugin-hermes-runtime`, `fusion-plugin-openclaw-runtime`) are also auto-installed on the first settings save for that bundled plugin card (lazy install on first `PUT /api/plugins/:id/settings`). They are **not** auto-installed at app boot or npm install time.
 
 2. Create agents with the appropriate `runtimeConfig`:
 
@@ -757,12 +759,14 @@ Common heartbeat/runtime keys on `runtimeConfig` include:
 | `heartbeatTimeoutMs` | `number` | Per-agent heartbeat timeout |
 | `maxConcurrentRuns` | `number` | Per-agent concurrent heartbeat limit |
 | `messageResponseMode` | `"immediate" \| "on-heartbeat"` | Wake on message immediately or process during periodic heartbeat |
-| `runMissedHeartbeatOnStartup` | `boolean` | Fire one startup catch-up heartbeat when the last tick was missed while the server was down (default `false`) |
-| `allowParallelExecution` | `boolean` | Permanent agents only. Default `true` when unset. Set `false` to serialize heartbeat and executor sessions symmetrically (heartbeat won't start while executor is active, and executor won't start while heartbeat is active); `false` is explicitly persisted while unset/`true` keeps parallel behavior |
+| `runMissedHeartbeatOnStartup` | `boolean` | Default `false`. When enabled, startup triggers one catch-up heartbeat if the agent's `lastHeartbeatAt` is older than its resolved heartbeat interval (server was down across a scheduled tick). |
+| `allowParallelExecution` | `boolean` | Permanent agents only. Default `true` when unset. Set `false` to serialize heartbeat and executor sessions symmetrically (heartbeat won't start while executor is active, and executor won't start while heartbeat is active); `false` is explicitly persisted while unset/`true` keeps parallel behavior. |
 | `selfImproveEnabled` | `boolean` | Enables periodic self-improvement prompts |
 | `selfImproveIntervalMs` | `number` | Delay between self-improvement cycles (default 4h, minimum 1h) |
 | `lastSelfImproveAt` | `string` | Last self-improvement checkpoint timestamp (managed by heartbeat monitor) |
 
+Configure these per agent in **Agents → Agent Detail → Settings → Heartbeat Settings** (dashboard), or by updating agent `runtimeConfig` via the Agents API/CLI config flows.
+
 These examples show agents configured to use Paperclip, Hermes, and OpenClaw runtime hints:
 
 ```json

docs/storage.md

@@ -6,7 +6,7 @@
 - **Backend settings keys defined in `@fusion/core`:** **78** total
   - **Global settings:** 17 (`GlobalSettings`)
   - **Project settings:** 61 (`ProjectSettings`)
-- **SQLite tables in project DB schema (`packages/core/src/db.ts`):** **39** (including migration-created tables)
+- **SQLite tables in project DB schema (`packages/core/src/db.ts`):** **43** (including migration-created tables)
 - **Issues identified:** **9**
   - High: 2
   - Medium: 5
@@ -195,6 +195,10 @@ Additional backend notes:
 | `project_insight_run_events` | Append-only per-run lifecycle trail (`seq`, `type`, `message`, optional `status`/`classification`/`metadata`) used by cancel/retry/timeout auditing and API inspection. |
 | `todo_lists` | Project-scoped todo list metadata (`projectId`, title, created/updated timestamps). |
 | `todo_items` | Todo list items (`listId` FK) with completion state, completion timestamp, and deterministic `sortOrder`. |
+| `project_auth_users` | Project-scoped user identities (email/display name/active state) used for membership and session relationships. |
+| `project_auth_memberships` | Project-scoped membership records linking users to fixed v1 roles (`owner`, `admin`, `editor`, `viewer`). |
+| `project_auth_providers` | Per-project external auth-provider links for users (provider + external user ID + metadata). |
+| `project_auth_sessions` | Project-scoped auth sessions tied to a user + membership with expiry and revocation timestamps. |
 | `ai_sessions` *(migration-created)* | Persisted AI interactive sessions (planning/interview/subtask) with status and conversation history. |
 | `messages` *(migration-created)* | Inter-agent/user message mailbox storage. |
 | `agentRatings` *(migration-created)* | Agent performance ratings (1-5), optional reviewer metadata, and run/task attribution. |
@@ -213,6 +217,8 @@ Additional backend notes:
 | `eval_task_results` | Per-task eval outcomes linked to runs (`runId` FK cascade), including durable task snapshots, category scores, evidence references, deterministic/AI signal payloads, rationale, and follow-up suggestions. |
 | `eval_run_events` | Append-only eval run event trail (`runId` FK cascade, ordered by `seq`) for orchestration/debug auditing and downstream API/UI drill-down. |
 
+Scope boundary note: the `project_auth_*` tables are strictly project-database membership/auth domain data. They do **not** replace or migrate global remote-access credentials/tokens, daemon auth, or model-provider credential settings (which remain in their existing global/project settings stores).
+
 ---
 
 ## 5) Issues Found