chore(openspec): archive wave 6 and close the migration tracker

The merge creates the brand capability (two requirements) and extends the
catalog browse requirement with the brand filter, the sales sort and a real
sold count. openspec validate --all --strict stays green at 14 specs.

With every box now checked, docs/TBD-migrate-wave.md is deleted, as its own
instructions require. Its two durable notes move to the README instead of
disappearing with it:

- `nuxt build` does not typecheck, so a green build is not the type gate the
  verification section claimed. AGENTS.md told me to treat it as one, which is
  why waves 1-5 over-reported "builds pass" as evidence.
- the list of what stays deliberately mock: addresses, coupons, favourites,
  account stats, the seckill/collective/integral pages, reviews, and the
  fixed-data adapter itself, which the adapter spec requires for rollback.

The README's verification block also gains the real test count (29, not 16).

openspec/specs/catalog/spec.md

@@ -40,7 +40,7 @@ Each SKU SHALL carry `price_minor` (integer minor units) and an ISO `currency` c
 - **THEN** the API returns 400
 
 ### Requirement: Public product browse
-Public `GET /api/products` SHALL return only `published` products whose shop is active, and SHALL remain readable without authentication. When `category_id` is supplied, the filter SHALL match that category **and every category beneath it**, so requesting a parent category returns products assigned to its child and grandchild categories. The listing SHALL accept an optional `sort` of `price` together with an `order` of `asc` or `desc`, ordering by each product's lowest active SKU price; any other `sort` value SHALL be rejected with a 400 `ApiError` rather than silently ignored. An unsorted listing SHALL order newest first. Paging SHALL keep returning `page` and `per_page` alongside the filtered `total`.
+Public `GET /api/products` SHALL return only `published` products whose shop is active, and SHALL remain readable without authentication. When `category_id` is supplied, the filter SHALL match that category **and every category beneath it**, so requesting a parent category returns products assigned to its child and grandchild categories. When `brand_id` is supplied the filter SHALL match that brand and compose with the other filters. The listing SHALL accept an optional `sort` of `price` or `sales`: `price` orders by each product's lowest active SKU price, and `sales` orders by units sold across orders that reached payment, which SHALL also be reported per product as `sold_count`. Any other `sort` value SHALL be rejected with a 400 `ApiError` rather than silently ignored. An unsorted listing SHALL order newest first. Paging SHALL keep returning `page` and `per_page` alongside the filtered `total`.
 
 #### Scenario: parent category includes descendant products
 - **WHEN** a shopper requests products for a category that has child categories holding published products
@@ -50,8 +50,16 @@ Public `GET /api/products` SHALL return only `published` products whose shop is
 - **WHEN** a shopper requests the product list with `sort=price` and `order=asc`
 - **THEN** products come back ordered by their lowest active SKU price ascending
 
+#### Scenario: sort by units sold
+- **WHEN** a shopper requests the product list with `sort=sales` and `order=desc`
+- **THEN** products come back ordered by their `sold_count` descending, and a product with no paid orders reports zero rather than being omitted
+
+#### Scenario: filter by brand
+- **WHEN** a shopper requests products with a `brand_id` alongside a `category_id`
+- **THEN** only products matching both filters are returned, and `total` reflects the combined filter
+
 #### Scenario: unsupported sort is rejected
-- **WHEN** a client requests a `sort` value that is not `price`
+- **WHEN** a client requests a `sort` value that is neither `price` nor `sales`
 - **THEN** the API responds 400 with an `ApiError` body instead of ignoring the parameter
 
 #### Scenario: unpublished products never appear