Live widget updates via SSE without full page reload

### Description

What problem would this feature solve?

The dashboard only refreshes widget data when the browser loads or reloads the page. If you leave it open, it goes stale - monitor statuses, prices, feed
items, etc. stay frozen until you press F5. For a dashboard meant to be glanced at passively (on a wall display, a second monitor, a phone), this defeats
the purpose.

Are there any potential downsides?

- Each open browser tab holds a persistent HTTP connection to the server. On most self-hosted setups this is negligible, but it's worth knowing.
- Widgets that render relative timestamps (e.g. "3m ago") will trigger a DOM update every time they're re-fetched even if the underlying data hasn't
changed, because the rendered HTML differs. Minor visual flicker, no functional impact.
- Reverse proxies (nginx, Caddy, Traefik) need to be configured to allow long-lived connections and disable response buffering on the /api/events path,
otherwise SSE silently breaks.

What would the configuration look like?

server:
live-updates: true # default: false

One flag. Off by default - disabling it leaves behaviour 100% identical to today, with no new goroutines or endpoints.

Are there any existing examples in other software?

- Grafana refreshes panels on a configurable interval via polling
- Home Assistant uses WebSockets to push state changes to the dashboard in real time
- Netdata streams metrics to the browser via SSE
- SSE is the simpler, HTTP-native alternative to WebSockets for this use case - one persistent connection, server pushes, no special protocol

External documentation relevant to implementation:

- MDN: Server-Sent Events
- MDN: EventSource API
- nginx: proxy_read_timeout and X-Accel-Buffering: no header to disable buffering for SSE connections

Anything else relevant?

There is a previous PR (#955) that attempted something similar. Its main issues were: a global event hub that broke hot-reload, auth checked after ID
lookup (enabling widget ID enumeration), widgets being polled on a fixed interval ignoring their configured cache duration, and event replay sent to newly
connected clients causing spurious refetches on page load. A correct implementation should address all of these.

Start with the /api/events entry point and the server.live-updates configuration, then review the earlier PR #955 and its listed failure modes. Done means live updates are opt-in, preserve configured cache durations, authenticate before widget ID lookup, avoid replaying events on connection, and do not break hot-reload.

Written by the indexing model from the issue text.