feat(cli): capture falls back to the well-known icon paths when a page declares none

[miguel-heygen]

Stacked on #3598 (open) — that PR adds the per-reason drop counts this one reuses. Review the top commit only.

The gap

capture built its favicon candidate list from the document's own
link[rel*="icon"] / link[rel="apple-touch-icon"] tags and nothing else
(packages/cli/src/capture/index.ts). A page that declares neither handed the
downloader an empty list, so the favicon loop in assetDownloader.ts ran zero
iterations: no fetch was attempted, and — even after #3598 — no drop reason was
emitted. A folder with no favicon because the site has none was byte-identical
to a folder with no favicon because nobody asked.

https://www.apple.com is in the second group: it declares none of the ~150
<link> tags in its head as an icon, and serves /favicon.ico (200,
image/x-icon, 22 KB) and /apple-touch-icon.png (200) anyway. Every browser
gets an icon there. Capture did not.

The change

When the page declares no icon link, the candidates become the site root's
well-known paths in the browser's own preference order — /favicon.ico, then
/apple-touch-icon.png — resolved against the page's final URL so a
redirect lands on the right origin. The first that answers wins.

• Declared links keep priority. When the page vouches for an icon, the
  well-known paths are never requested. The control test asserts the fetch call
  list, not just the result.
• A guess that misses is counted, never silent. It lands in the existing
  unavailable drop reason, so the dropped tally from feat(cli): capture reports why a referenced asset is not in the folder #3598 shows it.
• No new content-type logic. fetchBuffer already refuses an HTML or XML
  body served under a 200, which is exactly how a site with no icon answers
  /favicon.ico. That is what keeps an app shell from being written to
  assets/favicon.ico.

What I measured

Same command, same page, main-side build vs this branch:

$ hyperframes capture https://www.apple.com --skip-vision --json

before   "assets": 31   "dropped": { "size-floor": 0, "budget-exhausted": 0, "cap-reached": 20, "unavailable": 0 }
after    "assets": 32   "dropped": { "size-floor": 0, "budget-exhausted": 0, "cap-reached": 20, "unavailable": 0 }

before   $ ls capture/assets/favicon*
         zsh: no matches found

after    $ file capture/assets/favicon.ico
         MS Windows icon resource - 3 icons, 16x16, 32 bits/pixel, 32x32, 32 bits/pixel
         22382 bytes

One more asset, and it is the right one. unavailable stays at 0 because the
first well-known path answered, so the second was never requested.

Unit run: vitest run src/capture/assetDownloader.test.ts → 27 passed.
The three new tests were proved non-vacuous by reverting the one-line candidate
change: 2 of 3 fail (the declared-link control passes either way, which is the
point of a control).

What I did NOT exercise

• No end-to-end run against a site that declares no icon AND serves none.
  That path (both guesses miss, unavailable reaches 2) is covered only by the
  unit test with a stubbed 200-HTML response, not by a live capture.
• No local-server integration test. isPrivateUrl blocks loopback by
  design (SSRF denylist, F-003), so a fixture server on 127.0.0.1 can never be
  fetched by downloadAssets. Every existing drop-count test in this file stubs
  fetch for the same reason, and these follow that convention.
• Redirect handling is reasoned, not measured. page.url() returns the
  post-redirect URL and that is what the paths resolve against, but I did not
  capture a site that redirects across origins to confirm it end to end.
• --skip-vision on both runs. The vision pass does not touch favicons, but
  the before/after numbers are from that configuration, not the default one.
• Repo suite not run whole. vitest run src/capture gives 153 passed with
  3 collection failures from an unbuilt workspace package (@hyperframes/parsers
  has no dist in this worktree) — pre-existing, unrelated to this diff, and
  present on the base commit too.