feat: add opportunity type selector to coordinator edit form

[nadavosa]

Summary

Coordinators (and admins) can change an opportunity's type directly from the opportunity profile page, next to "Volunteering type" — same pattern as "Change status".

• Adds a "Change type" action to the OpportunityHeader profile card, opening a dialog (reuses the existing useStatusDialog/ChangeStatusDialog machinery already used for status changes).
• New useUpdateOpportunityType hook (mirrors useUpdateOpportunityStatus) with its own narrow request type — sends PATCH { volunteerType }, doesn't depend on ApiOpportunityPatch having volunteerType yet, so this isn't blocked on SDK PR landing event page #138 publishing for typecheck purposes.
• Per-option descriptions in the dialog cover what issue feat: allow changing opportunity type in dashboard profile (accompanying / regular / event) #753 asked for: switching to Accompanying explains that accompanying details need to be added afterward; switching away from Accompanying notes that existing accompanying details stop being used.
• EN/DE translations added.

Not added: new form fields for accompanying details — coordinators fill those in via the existing Accompanying Details section, as today.

Revision history

Original version of this PR added the type selector to the OpportunityDetails edit form (buried further down the page) instead of the profile header the issue asked for, had a stale isEventType bug (computed from the initial opportunity prop, not the live form value, so switching type mid-edit didn't switch the rest of the form), and didn't cover the accompanying-transition behavior. Reworked per review.

Dependencies

1. SDK PR feat: add volunteerType to ApiOpportunityPatch sdk#138 (adds volunteerType to ApiOpportunityPatch) — no longer a hard blocker for this PR's typecheck, since the new PATCH payload type is defined locally, but still needed for be#731 to land without its as unknown as cast.
2. BE PR feat: allow changing opportunity type via PATCH be#731 (handles the field server-side)

Closes #753

Test plan

• Open an opportunity in the coordinator dashboard → profile page
• "Volunteering type" row shows a "Change type" action, same as "Current status"
• Opening it shows Accompanying / Regular / Events with descriptions
• Selecting a new type and saving sends PATCH { volunteerType }
• The header updates to show the new type after saving
• Both English and German labels/descriptions render correctly
• yarn typecheck and yarn lint pass

🤖 Generated with Claude Code

[ivannissimrch]

Tested on dev.need4deed.org as admin (opp 821). The dialog works and the PATCH fires to /opportunity/821 with volunteerType, but the change doesn't persist PATCH returns 204 and the refetch still shows the old type. So the BE accepts the request but isn't applying volunteerType yet (be#731 not deployed on dev). FE looks correct can't verify the save end-to-end until be#731 lands.

Minor: the success toast shows even when nothing changed (BE returns 204) should resolve once the handler's in, but worth a glance later.

[ivannissimrch]

line 435 and 437 lngis undefined here (the route param islang, not lng), so these render /undefined/data-privacy`. #752 already fixes this by dropping the lang segment might be cleanest to drop these from this PR so the two don't conflict?

[nadavosa]

Self-review notes from going back through this PR (flagging before it's ready to re-request review, once the conflicts are resolved):

1. Merge conflicts — GitHub shows this PR as conflicting with develop. Needs a rebase before anyone can review the current diff meaningfully.

2. useOpportunityTypeDialog.ts — initial: opportunity.volunteerType as OpportunityType casts with no fallback for a missing/undefined volunteerType. Compare with useOpportunityStatusDialog, which normalizes via SDK_TO_MANUAL[status] ?? OpportunityManualStatusType.NEW. OpportunityHeader.tsx itself treats volunteerType as possibly falsy (opportunity.volunteerType ? ... : undefined), so if an opportunity has no type set yet, opening "Change type" would initialize selected to undefined with no option pre-selected — worth adding an explicit fallback for consistency.

3. BecomeVolunteer.tsx change is unrelated scope — the diff swaps Subpage.DATA_PROTECTION → Subpage.DATA_PRIVACY and reorders the URL segments for the consent links. I checked against the actual routes (src/app/[lang]/(static_pages)/data-privacy, .../agreement) and the new code is correct — the old code was pointing at a mismatched path. So this looks like a legitimate fix, just completely unrelated to the opportunity-type feature and not mentioned in the PR description. Worth calling out explicitly (or splitting into its own PR) so it doesn't get lost/attributed to the wrong change.