Finalized-poll lock is a banner only, unenforced server-side

[leahpeker]

Context

Surfaced while reviewing the survey PR batch (#1458–#1467); pre-existing, not introduced by any of them.

SurveyBuilderScreen renders "this poll has been finalized — the survey is locked" once a survey has a DatetimePollResult. Nothing enforces that lock. update_survey in backend/community/_surveys.py has no finalized check at all, and neither do the question endpoints.

So after finalizing a poll an admin can still change the survey's title, slug, visibility, description, one-response-per-user and linked event; add, edit, delete and reorder questions; and close or reopen it. The banner is decorative.

PR #1473 widens what that gap exposes by adding a settings dialog, but does not create it — the close/reopen toggle and the question dialog already had it.

What needs to happen

Decide what the lock should actually mean, then enforce it server-side rather than in the UI.

Probable shape: once poll_result exists, reject question mutations and changes to poll-affecting fields with a specific validation code, while still allowing harmless edits (title, description). Reopening a finalized poll, if permitted at all, should be a deliberate separate action.

Whatever is decided, the frontend should disable the controls the backend will reject so the UI and the rule agree.

Acceptance criteria

• the intended lock scope is written down in the issue or a code comment before implementing
• the backend rejects in-scope mutations on a finalized survey with a specific code
• the builder disables the controls that would be rejected
• tests for each rejected mutation and each still-permitted one