Activity polling uses the client's default organization, so sub-organization activities cannot be polled #30

_poll_for_completion in the generated client calls get_activity with GetActivityBody(activityId=...) and lets the client fill organizationId from its default. When an activity was submitted with an explicit organizationId that differs from the default, which is the normal case for a parent organization acting in a sub-organization, the poll asks the wrong organization. The activity is not found there, so the typed method fails even though the activity completed.

Follow-up: carry the submitting organizationId from the request body into GetActivityBody when polling. The initial response also carries activity.organizationId, which can be used as the source of truth. Add an offline test that submits with an explicit sub-organization id and checks the poll request carries the same id.

Seen while building a toolkit that creates one sub-organization per end user with a parent API key. The toolkit works around it with a client subclass that overrides polling.

Depends on #20 and #21, since both change the generator around this code.