ActivityCollector: two parallel implementations should be unified

[mgoldsborough]

Problem

Two `ActivityCollector` implementations exist with different ctor shapes and different data sources:

File	Reads from	Subscribes to
`src/services/activity-collector.ts` (canonical)	`ConversationStore` (DB-backed)	`SseEventManager` for bundle events
`src/bundles/home/src/services/activity-collector.ts` (bundle)	Conversation JSONL files on disk	— also tracks automation runs

These aren't drift of one implementation — they're architecturally different shapes for different deployment modes (in-process service vs. standalone MCP server). Their callers diverge too:

• `tools/core-source.ts` (the `home_briefing` tool) → uses canonical
• `tools/platform/home.ts` (the `home_activity` tool) → uses bundle

So two adjacent tools in the platform serve "what's been happening in this workspace" using different storage backends and different schemas. Risks:

• Inconsistencies between briefing and activity views (different conversation counts, different bundle event coverage)
• Bug fixes need to be applied in both places (or quietly drift)
• New contributors don't know which one to extend

Decision needed

This is an architectural call, not a hygiene fix:

• (a) Merge into one with capability flags (DB-backed vs file-backed selectable at construction; automation tracking opt-in) — single source of truth, but the merged class needs to handle both invocation contexts cleanly
• (b) Keep both, document why — codify the deployment-mode rationale in the file header so the parallelism is intentional rather than accidental

Context

Surfaced during PR #219 review. The briefing-resilience work touched the canonical path; the bundle copy is still alive because `tools/platform/home.ts` consumes it. Worth resolving before the next contributor stumbles on it.