v1.15.1

Tisty 1.15.1

Nothing to migrate: the log stays on schema 13, so this build and 1.15.0 read
each other's stores and you can update one machine before the other. Nothing
under the hood changed, so the first opening is as quick as any other.

A copy built for development wrote itself where Windows opens things at login

Turning on «open at login» writes the path of the copy you are running where
Windows reads at startup. A copy built for development answers to that too, and
it did: told to wake at login it registered itself, and after a restart Windows
opened that one instead of the installed one — a copy that only works while its
development server is up, so what came up was a page saying localhost had
refused the connection. The installed Tisty was fine all along, it was just not
the one that opened.

Such a copy no longer offers the switch and writes nothing, on any system. macOS
already refused it, because a bare binary sits in no application bundle; Windows
now says the same. A machine that already carries the entry keeps it until it
is removed by hand, since the installed copy has no say over what another one
wrote.

An update the Store still owes gets a door to the Store

A copy the Store keeps is told, in About, that the Store brings the update once
it has it and that Tisty has to be closed — tray icon and all — for Windows to
put it in place. The telling now comes with a button: «Open the Store» takes
you straight to its downloads and updates, where the queue that is holding the
update can be seen and nudged, instead of leaving you to find it.

What's Changed

• feat: an update the Store still owes gets a door to the Store by @rgdevment in #39
• fix: the week ahead is asserted on the hour it paints, not on a day by @rgdevment in #40
• fix: tauri dev guard by @rgdevment in #41

Full Changelog: v1.15.0...v1.15.1