Add a regenerate-slug button to the article editor

[ssavutu]

Editors had no way to fix a slug after an article was created — the field was read-only and the slug was frozen at whatever the title happened to be on the first save.

What this adds

A Regenerate from title button under the Slug field in the article editor.

• New article — fills the slug box with the slugified title.
• Existing article — the field stays read-only, but the regenerated slug is loaded into it as pending. It is only committed by an explicit Save/Publish; autosave never sends it, so an article's public URL cannot move on a 2.5s debounce. After the save succeeds the editor redirects itself to the new /articles/<slug>/edit, since the route it was on no longer resolves.
• Collisions — articles.slug has no unique index (it is LONGTEXT), so the button probes GET /v1/articles/<candidate> and falls back to -2, -3, … up to -20 rather than pointing two articles at one URL. The article's own slug counts as free.

Server side needed no changes: PATCH /v1/articles/{slug} already accepts and validates a slug field.

Known gap

There is no redirect table, so a regenerated slug leaves the old URL as a hard 404 rather than a 301. The pending-state hint warns about this and offers a "Keep the current slug" escape, but that is the only mitigation — worth a follow-up before this gets used much on published articles.

Supporting changes

• slugifyCategory → slugify; it already matched the server's CanonicalizeSlug rules exactly.
• The slug <label> was split so the buttons underneath are not read out as part of the field's accessible name.

Testing

Three tests added covering the autosave exclusion, the explicit-save path, and the -2 suffix. Full frontend suite passes (11 tests). Typecheck is clean apart from pre-existing TrixEditor.tsx errors; lint shows only the pre-existing saveArticle dependency warning.

🤖 Generated with Claude Code