A Context7 refresh already in progress is not a failure

[navbytes]

The Context7 refresh job added in #122 turned the docs workflow red on its
first real run
(32650278549):

HTTP 400
{"error":"user-has-active-task","message":"You already have a library being
 processed. Only one library can be processed at a time."}

What that told us

The integration is correct. It authenticated, resolved
/navbytes/vee, and came back with a domain-level answer rather than a
transport or auth error — which is the confirmation #122 said it could not give,
since there was no key to test with at the time.

Context7 allows one library per account to be processing at a time, and a
refresh was already underway when this fired.

What was wrong

The step treated every non-2xx as fatal. user-has-active-task is not a failure
to request a re-index — it means one is already happening, which is the
outcome the job exists to produce.

Left as-is, a docs deploy goes red for having asked twice. Two pushes in quick
succession is exactly when that happens, so this would have been a recurring
false alarm on a job whose whole point is to be quietly reliable.

The fix

That one error is treated as success; everything else still fails. Matched on
the error body, not on 400 alone — a 400 for any other reason is a real
failure and still exits 1.

Verified against the four response shapes that matter:

HTTP	body	result
200	{"status":"queued"}	pass — requested
400	{"error":"user-has-active-task",…}	pass — already in progress
401	{"error":"unauthorized"}	fail
404	{"error":"not-found"}	fail

The deploy job in that run succeeded; only this step failed, so the published
site was never affected.

https://claude.ai/code/session_01Hpit6cxJxkbmRfNu6UJGr5