We should return CORs headers when we send a 429

### Problem

Right now, when someone hit's a 429 we don't send a CORs header.
As such, if someone is making a client side app they won't even be able to see it's a 429.
When we return a 429 we should have the same CORs headers we use for APIs in general.

If Nginx handles the 429s then we probably need to configure this there.

### Reproducing the bug

1. Go to ...
2. Do ...

* Expected behavior:
* Actual behavior:

### Context

You can see related issues where people complain about this for other APIs
https://forum.companieshouse.gov.uk/t/cors-headers-missing-from-429-response/5209
https://community.cloudflare.com/t/cors-on-rate-limit-429/270010

### Breakdown

#### Requirements Checklist
* [ ]

#### Related files

*

#### Stakeholders

*

#### Instructions for Contributors

- Please [run these commands](https://github.com/internetarchive/openlibrary/wiki/Git-Cheat-Sheet#working-on-your-branch) to ensure your repository is up to date **before** [creating a new branch](https://github.com/internetarchive/openlibrary/wiki/Git-Cheat-Sheet#making-changes-and-creating-a-pull-request) to work on this issue and **each time after** pushing code to Github, because the pre-commit bot may add commits to your PRs upstream.

Start by tracing where 429 responses are generated and check whether Nginx handles them, as the issue suggests. Compare those responses with the CORS headers used for APIs generally; done means client-side applications can read the 429 response and the relevant behavior is covered by an appropriate verification.

Written by the indexing model from the issue text.