PATCH /opportunity/{id} silently drops agent address/district in in-place edit

[arturasmckwcz]

Context

Follow-up from review of #540 (cc @nadavosa).

The in-place agent edit path of `PATCH /opportunity/{id}` only maps `agent.name → Agent.title`. The `agent.address` and `agent.district` fields accepted by the request schema are never applied — a coordinator editing the RAC address/district via the old free-text form has their change silently lost.

This predates #540; it was called out during review since that PR touched the surrounding code.

Current behavior

`src/services/dto/parser-opportunity-patch-data.ts` builds the agent patch as:

```ts
agent: agentBody && agentBody.id === undefined
? ({ title: agentBody.name } as Partial) // address, district dropped
: {},
```

Note: `address` and `district` are not plain columns on `Agent` — `address` is an `Address` relation (`addressId`) and `district` is a `District` relation (`districtId`), so persisting them is not a trivial column write.

Options

1. Deprecate & remove the free-text `{ name, address, district }` shape once the frontend cuts over to the agent picker (the direction of Accept agent reference (agent.id) on PATCH /opportunity/{id} #539). The SDK already marks `name`/`address`/`district` `@deprecated` on `ApiOpportunityPatch.agent` as of 0.0.86. This is the recommended path.
2. Actually persist `address`/`district` by resolving the relations — only worth it if in-place editing must survive alongside the picker.

Acceptance

• Decide between (1) and (2).
• If (1): remove `address`/`district` from the patch shape (BE schema + SDK) so the API no longer advertises fields it ignores.
• If (2): `PATCH` with `agent.address`/`agent.district` is reflected on a subsequent `GET`.