## Context

`/api/admin/shops/fund-summary` 通过 `GetPrimaryAccountsByShopIDs` 查询 `is_primary = true` 的账号来获取店铺主账号信息（用户名、手机号）。

问题根因：`shop/service.go` 创建店铺初始账号时从未设置 `IsPrimary: true`，导致所有账号的 `is_primary` 均为默认值 `false`。数据库验证确认：系统中唯一一个店铺账号（id=128）的 `is_primary = false`。

## Goals / Non-Goals

**Goals:**
- 修复店铺创建逻辑，初始账号设 `IsPrimary: true`
- 数据迁移修复存量数据（每个店铺选最早创建的代理账号设为主账号）
- fund-summary 接口返回正确的用户名和手机号

**Non-Goals:**
- 不修改 `GetPrimaryAccountsByShopIDs` 查询逻辑（查询本身是正确的）
- 不实现"切换主账号"功能（超出范围）
- 不修改 fund-summary 的其他字段

## Decisions

### 决策1：修代码，不改查询

**选择**：在 `shop/service.go` 创建账号时加 `IsPrimary: true`，而非修改 `GetPrimaryAccountsByShopIDs` 为"查最早账号"。

**理由**：`is_primary` 字段本身语义明确（"是否为主账号"），查询逻辑是正确的。改查询是绕过问题而非解决问题，且未来如果引入"多账号切换主账号"功能会与改查询的方式冲突。

### 决策2：历史数据修复策略

**选择**：迁移 SQL 对每个 shop 取 `created_at` 最早的代理账号（`user_type = 3`）设为 `is_primary = true`。

**理由**：最早创建的账号最可能是初始主账号。这个规则简单确定，无歧义。

**SQL**：
```sql
UPDATE tb_account a
SET is_primary = true
FROM (
  SELECT DISTINCT ON (shop_id) id
  FROM tb_account
  WHERE shop_id IS NOT NULL
    AND user_type = 3
    AND deleted_at IS NULL
  ORDER BY shop_id, created_at ASC
) earliest
WHERE a.id = earliest.id
  AND a.is_primary = false;
```

## Risks / Trade-offs

**[风险] 一个店铺有多个账号时选错主账号**
→ 当前系统只有 1 个店铺且 1 个账号，风险极低。取最早账号的策略合理。
→ 如有异议，超级管理员可手动修正（未来可开放"设置主账号"接口）。

**[风险] 迁移 SQL 误更新已手动设置的 is_primary = true 记录**
→ SQL 加了 `AND a.is_primary = false` 条件，不会覆盖已正确的数据。

## Migration Plan

1. 执行代码变更（shop/service.go 加 `IsPrimary: true`）
2. 执行数据库迁移文件（UPDATE SQL）
3. 验证：调用 fund-summary 接口，确认返回正确用户名和手机号