feat: asobi retention, set how long an environment keeps unclaimed guests

[Taure]

Pairs with widgrensit/asobi_saas#286, which adds the route.

Why

Unclaimed guests are accounts nobody ever signed in to claim. Nothing removes them unless the environment says how long to keep them, so a game minting a guest per device accumulates them for ever - one live environment reached 254.

That became settable in the dashboard last week, but not here, while asobi resize has always written the neighbouring per-environment value from the CLI. There was no principle behind the split, just where the previous change stopped. The people most likely to want this are the ones already in a terminal cleaning up test debris.

asobi retention prod --after 30
asobi retention dev --after 7
asobi retention prod --after never

Decisions worth reviewing

--after is required and has no default. Retention deletes player accounts permanently and the server's sweep writes no audit row, so the period is spelled out on every invocation rather than inherited from a config file or a previous value.

never is sent as a value, not an omitted field. Turning retention back off has to reach the server as a decision. TestSetRetentionSendsNeverExplicitly pins that - omitting it would read server-side as a request naming no period, and be refused.

The local list is a convenience, not the guard. RetentionPeriods saves a round trip on a typo; the control plane validates against its own list regardless. 1 is absent from both - a one-day retention would erase a working game's whole guest population overnight, and it is refused for not being offered rather than by a bound somebody can talk themselves into moving.

A 403 is reported as a role refusal. Guest retention is owner/admin only. The generic retention failed (403) sends somebody off to re-run asobi login to fix a permission they do not have, so that status gets its own message.

Checks

gofmt -l clean, go vet clean, go build ./..., go test ./... all pass (5 new tests). asobi help output checked.