Travel time

Closes #396.

Fredy has always shown how far a listing is from your addresses as the crow flies. In a city with a
river, a ring line and no bridge where you want one, that number is close to meaningless: two flats
the same kilometre away can be eight minutes and fifty minutes from the same office. This adds the
number people actually decide on.

In this release:

Real travel times on every listing. How long it takes to get from each of your saved addresses
to the flat, by public transport, car, bike or on foot.

Everywhere the distance already was. Listing detail page, map popups, listing cards and the
table, notifications (all 16 adapters and both email templates), and the MCP output.

A "reachable within" filter on both the listings overview and the map. Pick a mode and a
ceiling, for example public transport within 30 minutes. On the map it hides the pins that fail;
in the list it filters the page.

The real route drawn on the map. On a listing's detail page you can choose what the map draws:
straight line, driving, walking, or the public transport journey. A transit journey is drawn leg by
leg in the operators' own line colours, so an S-Bahn reads as an S-Bahn.

Settings → Addresses is now Settings → Travel time. Each address gets a preferred way of
travelling and, for public transport, a time of day. The old /settings/addresses URL redirects.

Estimated and exact

Two kinds of number...

Estimated is what the scheduled sweep produces. Once per address, Fredy asks the routing
service how long it takes to reach every stop in the region, then adds the walk from the closest
one to the front door. Hovering the "Estimated" chip opens a popover explaining that, and listing
the stops the number was worked out from with their travel time and walking distance, so you can
check it rather than take it on faith.

Measured against exact routing on seven destinations across Berlin, the estimate landed between
2 minutes optimistic and 4 minutes pessimistic on journeys of 18 to 49 minutes. This is done to save Transitous
from being overwhelmed with calls.

Exact is what you get when you open a listing. Fredy asks for the real journey, which also fills
in car, bike and walking times and the drawable routes. That result is stored, so it is only ever
paid for once, and the sweep never overwrites it with an estimate.

A mode that could not be routed is left out rather than shown as a zero,
and a listing that has not been measured yet says so instead of showing a plausible-looking number.
Notifications carry a commute only when a router actually produced one.

Why it is built this way

Travel times come from Transitous, a community-run MOTIS instance
maintained by volunteers. It needs no API key and no signup, which is why Fredy already used it for
the departure boards.

I described what Fredy wanted to do to the Transitous maintainers first. Their advice was to avoid
per-listing journey planning, because each one triggers street routing and that adds up to a lot of
CPU. So the question is turned around: one request per address answers for the whole region, and
the number of listings does not enter into it. For a typical instance that is a handful of requests
a day rather than several hundred.

Street routing happens in only two places, both bounded: a place public transport does not reach
(a village with no bus, where the driving time is the only answer there is), and an address you
asked to be measured by car or on foot. Both draw on the same small per-run budget, so those fill in
gradually rather than all at once. Opening a listing is the third, and that is one person looking at
one flat.

The straight-line distance is untouched and still shown. Where a lookup fails, that is what you see,
exactly as before.

Attribution

Routing data is provided by transitous.org/sources.

Full Changelog: 25.1.1...25.2.0