[DWAA1660]

What and why

Fixes #133. model::time::long_from_iso (and date_from_iso / clock_from_iso, built on it) took the clock straight from the stored UTC timestamp. A new page's date line, written by formats::templates, and Insert › Time / Date & Time therefore showed UTC with no zone. At 10:18 in Denver a new page said 17:18, and near midnight the date could be wrong too.

Stored timestamps stay UTC. Only what is shown changes:

• notecraft_model::time: a process-wide local offset (set_local_offset / local_offset, an AtomicI32 that defaults to 0). long_from_iso → new long_from_iso_at(iso, offset) converts a timestamp ending in Z to that clock, moving the day, month and year when needed. A timestamp with no zone is shown as written. It now also rejects an hour over 23 or a minute over 59.
• Desktop app (apps/notecraft/src/main.rs): on the first line of main, while it is the only thread, it reads time::UtcOffset::current_local_offset() and sets the model's offset. It logs the result. On Linux and macOS the time crate can only read the local offset safely while the process has a single thread, which is why it happens first.
• Dependency: time was already in the lock (via zip). The workspace now names it with features = ["std", "local-offset"] for the app only, which adds one small crate, num_threads (MIT/Apache-2.0).

With no offset set, everything behaves exactly as before: tests, notecraft-cli, the browser build, or a system that can't report one.

Not covered: the offset is read once at start, so a session running across a daylight-saving change keeps the old offset until restart. The UI is English-only, as before. Regional date formats would be a separate change.

How it was checked

• New time::tests::a_timestamp_is_shown_on_the_users_clock:
  • the issue's Denver case (17:18Z → 10:18 at −07:00), a +05:30 zone
  • moves to the previous day, the next year, and back onto a leap day
  • a zone-less timestamp shown as written, and an invalid hour rejected
• Existing time tests (all at offset 0) unchanged and passing
• cargo build -p notecraft, then notecraft --version runs
• cargo test -p notecraft -p notecraft-model -p notecraft-formats -p notecraft-store -p notecraft-engine: pass
• cargo test -p notecraft-ui-egui: all pass
• cargo xtask layers: pass
• cargo fmt --all -- --check, cargo clippy -p notecraft -p notecraft-model --all-targets -- -D warnings: clean

Not checked: on a machine set to a non-UTC zone. The conversion is unit-tested, and reading the offset relies on the time crate.

🤖 Generated with Claude Code

[DWAA1660]

Audit finding: the current UTC offset is applied to every timestamp, including dates in a different daylight-saving period. This can change the displayed calendar day.

Reproduced against this PR's actual time.rs with set_local_offset(-7 * 3600), matching Denver in November:

long_from_iso("2026-07-15T06:30:00Z")
=> "Tuesday, 14 July 2026, 23:30"

Windows TimeZoneInfo for Mountain Standard Time converts that same UTC instant to 2026-07-15 00:30, because July uses UTC-6. The January control agrees at UTC-7. An app left open across a clock change also keeps the stale startup offset.

Please resolve the local-zone offset for the timestamp being displayed, with winter/summer and midnight-crossing regression cases, rather than using a single offset captured at startup. Holding this out of the merge batch for the incorrect date display.