fix(ev): change ready time without a second passkey

[frahlg]

Why

Closes #71. On a signed-in phone, changing the car's ready time asked for a passkey again. Login already proved who is asking.

The box is the authority. This app still asks without stepUp first and only prompts on E_NEEDS_STEP_UP. Once Core accepts the schedule write, the prompt goes away on its own. The simulator has to match that price or the tests keep demanding Face ID.

What

• Simulator: schedule PUT/DELETE are Configure with noStepUp. Owner is enough. Viewer is still refused.
• Pairing, restart, vehicle size, and other configure writes still need a ceremony.
• EvPanel tests expect one schedule PUT and zero Face ID prompts.
• Protocol note matches the box: most configure still needs a step-up; the charging schedule does not.

Pair

Box change: srcfl/ftw#1228

An old app against a new box already saves without Face ID, because it never sends stepUp until refused. This PR is the honest sim, the tests, and the docs.

Tests

npx vitest run src/views/EvPanel.svelte.test.ts tests/api-passthrough.test.ts

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	ftw-webapp	a5d3d42	Commit Preview URL	Sep 13 2026, 10:39 AM

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-13T10:41:39.429171Z	a5d3d42	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[miravoss26]

Removes the step-up (passkey/Face ID) ceremony for charging-schedule writes (PUT/DELETE /api/loadpoints/{id}/schedule), via a new noStepUp route flag. Role check (owner) is unchanged and still enforced — verified by the new passthrough test that a viewer is still E_SCOPE_DENIED.

Security note (authz change, flagging per the screen, not blocking): this narrows the ceremony requirement for exactly two routes, deliberately and narrowly scoped, and the tradeoff is documented in docs/protocol.md ("the session already proved who is asking, and a second Face ID is more friction than the table-phone risk is worth"). Worth a human eyeball since it's a real authn-friction/risk tradeoff, even though the implementation matches the stated intent precisely.

• Tests are thorough and were properly flipped (not just relaxed) — the "ceremony fails" test now asserts the write succeeds without calling stepUp at all, rather than being deleted or weakened.
• Depends on the paired Core-side change (.changeset says "pair with the Core change") — reviewing that one separately, this PR alone won't do anything if Core still requires the flag.

No correctness issues found. The authz relaxation is the one thing I'd want a teammate's eyes on before merge, everything else safe to merge from my read.