Give project owners a user-facing interface for class masking #1406

Summary

Class masking (#999) has been running in production since 2026-07-03, but the only way to
use it is the Django admin, restricted to superusers. A project owner cannot see whether
masking is active on their project, cannot see which taxa list it uses, cannot see which
predictions it changed, and cannot turn it on or adjust it themselves. #997 asked for exactly
this design and was closed with an empty template body before any design happened; this
issue replaces it now that the feature it would sit in front of actually exists.

What a project owner needs to be able to do

• See whether class masking is enabled for their project, and which taxa list and algorithm
  it applies to.
• Turn it on, choose a taxa list, and turn it off, without going through the admin.
• See, for a given occurrence, whether its current classification is the result of masking,
  and what it would have been without it — the applied_to chain (Let admins mask classifier predictions to a species list #999) already carries
  this provenance; it needs a surface.
• See a summary of what a masking run changed before or after enabling it — count of
  classifications affected, count of occurrences whose determination changed — rather than
  discovering the effect one occurrence at a time.

What already exists to build on

• The provenance chain (applied_to, exposed on the occurrence and classification
  serializers) already carries everything needed to show "masking changed this."
• The post-processing framework (Framework for admins to trigger and review post-processing methods #1289) already has a Job-based execution path; this is
  primarily a question of what triggers it and what the project settings surface looks like,
  not new execution machinery.
• Generate a project taxa list from a region, and track which species the models can predict #1367 will add a project-level default_taxa_list and region fields, which is naturally
  where a masking on/off toggle and list picker would live.

Open questions

• Does this belong in project settings, or as a control near the occurrence list (closer to
  where its effect is visible)?
• Should enabling masking run automatically on future results only, or offer a one-time pass
  over existing predictions?
• How much of the admin-only surface (choosing reweight, choosing a specific algorithm)
  should be exposed to a project owner versus fixed to sane defaults?

Related

• Let admins mask classifier predictions to a species list #999 — class masking
• Generate a project taxa list from a region, and track which species the models can predict #1367 / Let users build a project taxa list from a region, so class masking works out of the box #1364 — regional taxa lists, the natural home for the list picker
• Framework for admins to trigger and review post-processing methods #1289 — the framework this would trigger through
• Design & discuss frontend component for Class Masking feature #997 — the original, closed without a design; this replaces it