fix: opportunity district resolution used the wrong source for both types

[nadavosa]

Description

getDistrictToOpportunityHandler's addDistrictToOpportunity (used by the opportunity list route, the legacy creation route, and the single-opportunity route) resolved an opportunity's district from two concepts that don't represent its own location:

• REGULAR/EVENTS used deal.dealDistrict[0], the deal's volunteer-search target district(s), an unrelated concept.
• ACCOMPANYING used deal.postcode, which mirrors the agent's own postcode (the exact same value the fallback branch right below it already derives independently), never the appointment's own postcode.

The fix

Per the correct rule in the issue:

• REGULAR/EVENTS: the opportunity's own agent's district, via agent.districtId. That's an already-loaded FK column wherever agent is loaded at all (no new relation needed, confirmed against the list route's existing relations).
• ACCOMPANYING: the appointment's own postcode, via accompanying.postcode (falling back to accompanying.postcodeId when only the FK is loaded, not the relation).
• Kept the existing fallback chain (agent's own address postcode) for whichever branch above doesn't resolve.

Related Issues

Closes #895

Changes

• src/server/utils/data/add-district-to-opp.ts: corrected district source for both opportunity types.
• src/test/server/utils/data/add-district-to-opp.test.ts: rewrote the unit tests, the old ones asserted the buggy behavior directly (e.g. "assigns district from deal location", "Priority 1: assigns district from deal postcode").

Testing

No Postgres available in my sandbox by default, spun up a throwaway instance (embedded-postgres, self-contained, no root/Docker needed) to run migrations, seed data, and the full suite for real rather than relying on unit tests alone.

• tsc --noEmit, eslint (changed files): clean.
• add-district-to-opp.test.ts: 11/11 passing (fully rewritten for the new behavior).
• Full suite against a real seeded DB: 797/798 passing. The one failure (swagger.test.ts, a 5s timeout on buildServer() startup) is a pre-existing, unrelated flake, confirmed passing on its own with a longer timeout, and already independently reported by another contributor on a different PR.

Checklist

• WITHIN THE SCOPE OF AN ISSUE; No unnecessary files included
• Tests added/updated
• Documentation updated
• CI passes