Add Dashwise Activity Layer

[andreasmolnardev]

Overview

This branch adds a reusable Activity Layer to Dashwise, based on experimental and targeting experimental.

• Adds a private PocketBase activities collection with owner relation, bounded fields, chronological and retention indexes, and per-owner/source idempotency index.
• Adds authenticated Hono APIs for publishing integration activities, querying/filtering/paginating, retrieving details, and deleting owned activities. Producers cannot set ownership or source; the backend resolves those from the authenticated user and integration record.
• Adds server validation and bounds for payload size, metadata size/depth, secret-like metadata keys, safe internal action paths, and per-user publish rate limits. Adds configurable retention cleanup based on server-generated creation time.
• Adds a typed @dashwise/integrationskit/activities publisher that calls the authenticated integration-scoped API without coupling integrations to PocketBase.
• Adds the configurable Activity Stream glanceable and authenticated activity history/detail pages, with source/type/severity/time filters, pagination, loading/empty/error states, and refresh from Dashwise's existing websocket snapshots.
• Emits owner-scoped activity events for monitor availability and news-feed failure/recovery transitions. Activity persistence failures do not stop those jobs.
• Keeps activities separate from notifications; the existing notification behavior remains intact.

Design decisions

• Reuses PocketBase, Hono, the existing authentication/session mechanism, and the current per-user websocket. No additional service or database is introduced.
• Leaves the legacy latest-activities glanceable behavior in place and adds a separate activity stream to avoid changing existing dashboards unexpectedly.
• PocketBase collection rules deny direct client access; backend routes enforce owner scoping.
• The existing experimental branch contains no file-sharing or snippets prototype to preserve. No sharing/snippet production functionality is introduced.

Migration

A new migration creates the private collection and indexes. It has no data backfill. Existing installations should apply it through the normal PocketBase migration flow. The migration test checks the collection definition, bounds, indexes, and private rules from source; it was not executed against a live PocketBase installation in this task.

Verification

• bun run test — 43 passed, 0 failed (159 assertions).
• bun run check — passed (lint, workspace typecheck, generated OpenAPI consistency).
• bun run build in apps/backend — passed.
• bun run build in apps/web — passed; Vite emitted a large-chunk warning for the Widget bundle.
• Activity-specific tests cover validation, owner isolation, integration attribution, idempotency and unique-key race recovery, retention, unauthenticated route rejection, SDK validation, action safety, and migration structure.

Security

Ownership/source values are resolved server-side. Read, detail, delete, integration publishing, and realtime invalidation are scoped to the authenticated owner. Direct PocketBase API rules for activities are private. Payloads are bounded and reject secret-like metadata keys; action targets must be safe same-origin paths. Producer activity failures are caught so monitoring and feed jobs continue.

Known limitations

• PocketBase fresh-install/upgrade/rollback and actual database access-rule behavior were not exercised against a running PocketBase instance.
• Frontend websocket/component behavior has no dedicated component-level test yet. No app or browser was started, per the requested constraint.
• File sharing and snippets are not present on the base branch and remain outside production scope. If introduced later, keep them experimental and publish only bounded status or opaque identifiers, never file/snippet contents.