v0.1.3

This release fixes cases where Belune reported success while quietly doing
something else: backups that looked restorable but were not, a deletion that
destroyed more than it admitted, and a feature that accepted configuration it
never applied.

Backups now record where they were written

A backup stored its object key but not its destination. At restore time the
destination was resolved by following the backup's schedule to whatever that
schedule pointed at right then — and a schedule is editable. Repoint one, or
delete it, and every backup it had already produced pointed at storage its data
was never in. Nothing surfaced until a restore was attempted, which is the worst
possible moment to find out.

Backups now record the destination they were actually written to, and restores,
retention and cleanup all read that record instead of re-deriving it. Existing
backups are backfilled with their schedule's current destination — the same
answer the old code would have given, frozen so it can no longer drift.

Two new restrictions follow from this, and both are deliberate:

• A destination holding backups cannot be deleted. The error names how many.
• A destination's type, endpoint and bucket cannot be changed once it holds
  backups. On AWS S3 the region is locked too, because with no explicit endpoint
  the region is the address. Name, prefix and credentials stay editable —
  rotating an access key is expected and moves nothing.

To write to different storage, add a second destination and point your schedules
at it. The original keeps serving restores of what it already holds.

This does not recover backups already lost. If a destination was repointed
before upgrading, Belune has no record of where those objects went; they will
still fail to restore even though the backup list shows them as successful.
This stops the bleeding — it cannot undo it.

Deleting a database now says what it destroys

Deleting a database also deletes every backup ever taken of it, remote copies
included. Nothing said so. The dialog now states how many backups will go and
names the destinations holding them, requires typing the database name, and
records the count and destinations in the audit log — so "where did those
backups go" has an answer afterwards.

The count deliberately counts artifacts, not rows: a failed backup that never
wrote a file is not counted, so the dialog does not promise to destroy something
that was never there.

Known gap: deleting a project removes its databases and their backups the
same way, without itemising any of it. Delete databases individually if you want
the consequences spelled out first. Tracked in #3.

Per-domain rate limiting withdrawn

The rate_limit route feature was accepted, stored, and then emitted no proxy
configuration at all — the bundled Caddy image has no rate-limiting module, so a
domain could look rate-limited while being wide open. It is now refused with an
explanation rather than silently ignored, and returns in 0.2.0 with the custom
Caddy image.

The dashboard never offered this feature, so it could only have been set through
a direct API call. Existing rows keep serving traffic — the route still builds,
now with a warning naming the domain. This does not affect Belune's own
per-user API rate limiting, which is unchanged.

Configuration warnings

Installs created before v0.1.0 carry JWT_EXPIRY_HOURS=24 in their .env,
issuing access tokens valid 24x longer than the current default of 1 hour.
Access tokens cannot be revoked, so a stolen one stays usable for that whole
window.

Belune now warns at startup and on the Projects page when the value exceeds 12
hours. Remove the line from your .env and restart — sessions are
unaffected, since refresh tokens already cover them. update.sh deliberately
does not edit your .env for you: silently rewriting an operator's
configuration during an upgrade is a worse precedent than the setting itself.

Upgrading

Run update.sh from your install directory as usual. No host update is
required, and no infrastructure restart: this release adds one forward-only,
additive migration and touches nothing in infra/ or scripts/.

Take a backup first, as with any 0.x upgrade.

Install

curl -sSL https://raw.githubusercontent.com/weiliang79/belune/v0.1.3/scripts/install.sh \
  | BELUNE_VERSION=v0.1.3 bash

Upgrading an existing install: run update.sh from your install directory.
Take a backup first — 0.x minor releases may contain breaking changes.

Full changelog: v0.1.2...v0.1.3