Investigate frame protection for the console

The console sends no frame-protection header, on either deployment:

```
$ curl -sS -D - -o /dev/null https://pay.filecoin.cloud/console | grep -iE 'x-frame-options|frame-ancestors'
(nothing)
$ curl -sS -D - -o /dev/null https://filecoin-pay-explorer-staging.vercel.app/console | grep -iE 'x-frame-options|frame-ancestors'
(nothing)
```

`apps/explorer/next.config.ts` has no `headers()` block, so nothing sets one.

## What it would buy

`X-Frame-Options: DENY`, or CSP `frame-ancestors 'none'`, stops another origin embedding the console in an iframe. The browser enforces it against our response, so an attacker cannot strip it; they would have to alter a response in flight, which TLS prevents.

## Why it may not be worth much

The authorization the console performs ends in a wallet confirmation, and that dialog is extension UI. It renders outside the page, cannot be framed, cannot be overlaid, and names the contract call. A clickjack can land a click on "Review & authorize" but cannot complete the grant, so the header does not close an attack that works today.

Other console surfaces may be cheaper to abuse than the authorize flow; that is the part worth looking at before deciding.

## Ask

Decide whether to add it. If yes it is a `headers()` block in `next.config.ts` and nothing else. If no, say so here so the next person does not re-open the question.

Related: hardening the CLI pairing flow it serves, the filecoin-pin hardening tracker (linked in a follow-up comment)

Start with apps/explorer/next.config.ts and reproduce the two curl checks against the production and staging console URLs. Review the other console surfaces and the authorization flow described in the issue before deciding whether frame protection closes a meaningful risk. Done means either documenting the decision not to add it or adding the headers() block and confirming the response header.

Written by the indexing model from the issue text.