feat(ai): add bulk record_activities tool for AI assistant

[kwaich]

Description

Adds a new record_activities AI tool that allows the assistant to record multiple investment activities in a single interaction, complementing the existing single-activity record_activity tool.

Changes:

• Backend (Rust): New record_activities tool with batch save logic; registers in tool registry, chat.rs, and system prompt
• Frontend: New RecordActivitiesToolUI with per-row status tracking, confirm flow, and error display
• Shared utils: Extracted activity table formatters (shared/activity-table-utils.ts) to eliminate duplication between the search and record UIs
• Tests: Unit tests for record-activities-tool-utils.ts

Checklist

• I have read and agree to the Contributor License Agreement.

By submitting this PR, I agree to the CLA.

[afadil]

Hi, wondering if it's better re-use the exisiting csv import and adapt it for both bulk record and import.

[kwaich]

Hi @afadil, good question. I looked at both paths before deciding to keep them separate.

Both tools share the same save path (saveActivities() → bulk_mutate_activities()), but their input processing is quite different.

Input shape mismatch

• import_csv starts with raw CSV bytes and does a lot of heavy lifting: parsing headers, auto-detecting field mappings, normalizing dates/numbers/activity types, and building CsvActivityDraft rows.
• record_activities receives pre-structured LLM args and builds ActivityDraft rows directly, no parsing needed.

Forcing one through the other's pipeline would either break import_csv by stripping out its parsing logic, or add unnecessary overhead to record_activities.

Intermediate model mismatch

• CsvActivityDraft carries CSV-specific fields like row_number, raw_values, errors[], warnings[], applied_mapping, cleaning_actions, and detected_headers.
• ActivityDraft carries AI-specific fields like price_source, is_custom_asset, pricing_mode, and asset_kind.

Unifying them would mean populating irrelevant fields with dummy values on both sides, which feels like the wrong tradeoff.

The shared layer already exists
Both paths converge at saveActivities() → bulk_mutate_activities() → prepare_activities_for_save() → repository, which I think is the right abstraction boundary.

That said, I'd love to hear your thoughts if you see it differently. There may be angles I haven't considered!