feat: store and reuse the hosted-report writeToken on POST

[serenakeyitan]

Summary

The website API now binds hosted-report ids to their first publisher (first-tree-website PR pairs with this one): the first POST for an id returns a one-time writeToken, and every later POST of the same id — i.e. a same-day re-scan — must send it as Authorization: Bearer <writeToken> or the API answers 401. This closes the hole where any anonymous caller could overwrite any hosted report.

Scanner-side contract changes (Step 7 / Step 9.5 / checklist):

• On 201: merge any returned writeToken into .production-scan/write-tokens.json (created if missing). The token is shown exactly once.
• Before POSTing: if write-tokens.json holds a token for this id, attach the Bearer header.
• On 401: the id is claimed and we don't hold its token — append -2 to the id and resubmit once (same recovery shape as the reserved-id 400 rule). Never re-send an identical 401 body.
• .production-scan/ stays gitignored; the tokens file is one more reason.

Sequencing

Land soon after the website-side change deploys: until then, an old scanner doing a same-day rescan gets a 401 and falls back to the honest local-report path (no broken links, but the overwrite flow degrades).

Test plan

• Website-side flow verified end-to-end against an Upstash REST mock (first POST mints token; anonymous/wrong-token overwrite 401; authed overwrite 201 latest-wins)
• Doc-only change here; instructions mirror the verified API behavior

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}