fix: prevent frontend from stripping hfToken during state sync

[qins]

Summary

This PR fixes a bug where the HuggingFace Token is never actually saved to the backend disk (cookbook_state.json), which causes auto-restarted or resumed gated model downloads to permanently stall.

When a user enters their HF Token in the UI, _stripStateSecrets in static/js/cookbookRunning.js aggressively strips the hfToken from the payload before the fetch request is sent. Consequently, the backend never receives the token. This PR modifies _stripStateSecrets to preserve the hfToken in the payload. It is perfectly safe because the backend already properly handles encrypting the token to disk (_state_for_storage) and stripping it from API responses (_state_for_client).

Target branch

• This PR targets dev, not main.

Linked Issue

Fixes #3589

Type of Change

• Bug fix (non-breaking — fixes a confirmed issue)
• New feature (non-breaking — adds new behaviour)
• Breaking change (changes or removes existing behaviour)
• Refactor / cleanup (behaviour unchanged)
• Documentation only
• CI / tooling / configuration

Checklist

• I searched open issues and open PRs — this is not a duplicate.
• This PR targets dev
• My changes are limited to the scope described above — no unrelated refactors or whitespace changes mixed in.
• I actually ran the app (docker compose up or uvicorn app:app) and verified the change works end-to-end. Type-checks and unit tests are not enough.

How to Test

1. Ensure you have no existing hfToken saved in cookbook_state.json.
2. Start Odysseus and input a valid HuggingFace Token in the UI Settings.
3. Observe that the /api/cookbook/state POST request payload now includes hfToken.
4. Check your backend cookbook_state.json file on disk — the token should now be present as an encrypted string.
5. Attempt to download a gated model. Stop the app midway to stall the download, then restart the app. The download should resume successfully instead of throwing gated/private models will be denied.