[fleizean]

Summary

The admin Jobs panel now shows, for every queued, running and finished Hangfire job, a readable job type, the package or record it works on, and what triggered it.

Why

The panel listed jobs only by their method name (IPackageTrustService.RefreshAsync, IPackageCacheService.GetOrFetchMetadataAsync), so it was impossible to tell which package a job was about or why it had been queued.

Changes

• JobDescriptions (Application) maps each job method to a label (Security scan, Metadata refresh, Release notes scrape, Cache refresh sweep, ...) and reads the target from the job arguments: registry and package, the version range of an AnalyzeRequest, a short audit id, a blog post id. Unknown jobs fall back to their humanised method name.
• JobTriggerFilter (API) is a global Hangfire client/server filter. When a job is created it stores a TriggeredBy job parameter: Job #id · <label> when enqueued from inside another job, Request · <METHOD> <path> when enqueued during an HTTP request (path only, no query string). Jobs created by the recurring scheduler are shown as Schedule · <recurring id> from Hangfire's own RecurringJobId parameter.
• RecentJobInfo / QueuedJobInfo gain JobType, Registry, Detail and TriggeredBy; JobName keeps the technical name, so the existing parent/child grouping is unchanged.
• Active Queue and Recent Job History get Type, Target and Triggered by columns; the technical name stays as a small second line under the type, and the server column shows the short server name with the full id as a tooltip.
• AddHttpContextAccessor() is registered for the filter.

Notes for reviewers

• Jobs created before this deploy have no TriggeredBy parameter and show "Not recorded" (recurring ones still show their schedule).
• The jobs overview now also reads job details for queued and processing jobs (up to 100 extra lookups per refresh, as already done for the history).
• Not built or run locally; CI is the check.

Checklist

• The pull request targets develop and is about one thing
• Commit messages follow Conventional Commits (feat(scope): ..., fix(scope): ...)
• CI is green (backend tests, frontend build and tests, dependency gate)
• Schema changes are EF Core migrations generated by the tool, not hand-edited (no schema change)
• A changed backend DTO has its TypeScript twin updated (the job DTOs are mirrored in admin-jobs.ts)
• New dependencies are justified and their lock files are updated in the same commit (none added)
• No secrets, tokens or personal data in code, logs or this description
• Code comments are kept to a minimum; the reasoning lives in this description