Redesign Activity around contacts and dApps

## Problem

The current Activity page is a flat, chronological transaction list. In research, people did not understand the Wallet's broader activity model or where flows such as receiving, swapping, and future bridging belong. Notes and claims are also exposed as a separate technical concept instead of an action the user needs to take to receive funds.

## Goal

Make Activity a task-oriented view of the user's relationships with people and apps. The top-level view should answer: **Who or what is this activity with, and is there anything I need to do?**

**Target date:** Sunday, August 30, 2026

## Pre-implementation decisions

Resolve these before implementation begins. Wallet already has an address book and transaction history records a secondary/counterparty address, so a new Contacts feature is not a dependency.

- **Contact resolution:** Group by the canonical Miden account/address. Display a saved address-book name when one exists; otherwise show a shortened address. Do not infer a person from an unverified name-service record in v1.
- **dApp attribution:** Define the durable transaction metadata needed to identify an originating dApp. Current history entries carry a counterparty address but not a persisted dApp identity, so record trusted dApp metadata when the transaction is initiated or place the transaction in an explicit ungrouped fallback.
- **Grouping precedence:** Decide where a transaction associated with both a saved contact and a dApp appears. A transaction must appear once only.
- **Claim model:** Enumerate the existing claimable flows that can appear in Activity and agree on one user-facing verb and set of states. This issue does not change auto-claim policy.

## Scope

- Replace the flat transaction feed on the Activity root with a chat-list-style grouped list.
- Group entries by contact/counterparty and by dApp, using the best currently available identity:
- saved contact name;
- known dApp name/icon;
- shortened address or existing transaction label as the fallback.
- Add top-level filters for **Contacts** and **dApps**.
- Each group row shows a recognizable identity, latest activity summary/time, and a pending-action indicator when it contains something the user must claim.
- Tapping a group opens its chronological detail feed, with the relevant claim action available there.
- Add a prominent pending/claim section or equivalent state so users can complete required actions without first understanding the internal note model.
- Preserve existing transaction statuses and details. This changes information architecture and language, not transaction truth.

## Acceptance criteria

- [ ] Activity opens to a grouped Contacts/dApps view instead of a raw transaction list.
- [ ] A user can open a group and see its full ordered transaction history.
- [ ] A pending claim is distinguishable from a completed or failed transaction and launches the existing claim flow from the relevant context.
- [ ] Unknown counterparties and transactions without dApp metadata remain visible; no activity is silently dropped.
- [ ] Existing Activity notification/badge behavior continues to surface required actions.
- [ ] The experience works on iOS, Android, extension popup, and full-page/desktop layouts.
- [ ] Tests cover grouping, the empty state, unknown counterparties, and a pending-claim path.

## Out of scope

- Building contacts, name service, bridge, Earn, or dApp-messaging functionality that does not already exist.
- Multi-account activity aggregation.
- The future AI-assistant interaction model.
- Changing whether a flow auto-claims.

## Design reference

Use an Alipay-style grouped activity pattern as a directional reference. The desired outcome is clarity and actionability, not a literal visual copy.