Workflows: fire an Unpublished trigger when an entry leaves Published, and fire Deleted on erase

Found while planning barakocms.com as a barakoCMS-backed site.

Taking a published entry down fires nothing. `WorkflowProjection.cs` maps a status transition to a trigger only in one direction:

```csharp
if (e.Data.NewStatus == barakoCMS.Models.ContentStatus.Published)
{
await ProcessEventAsync(barakoCMS.Models.WorkflowEvents.Published, ...);
}
```

Archiving a Published entry produces a `ContentStatusChanged` that matches nothing, so no workflow runs. `WorkflowEvents.Deleted` is declared in `Models/WorkflowEvents.cs` and no code path fires it either.

## Why this matters

Any workflow built around "the public view of this content changed" is half wired. Publishing notifies, unpublishing does not. For a site that rebuilds itself on publish, a takedown leaves the pulled entry live until something else triggers a build. That is the worst case for the one operation you most want to be fast.

## The information is already there

`Features/Public/Events/Models.cs` declares `content.unpublished` and the SSE stream emits it on exactly this transition. The projection sees the same event and drops it.

## What to change

Fire an `Unpublished` trigger when `OldStatus` was Published and `NewStatus` is not, and fire `Deleted` on erase so the declared constant means something. Both need adding to the trigger vocabulary the API exposes.

Start in WorkflowProjection.cs and compare its ContentStatusChanged handling with Features/Public/Events/Models.cs, which defines the unpublished transition. Read Models/WorkflowEvents.cs for the existing Deleted event, then trace the API trigger vocabulary. Done means unpublishing and erasing entries emit the corresponding workflow triggers and both are exposed by the API.

Written by the indexing model from the issue text.