Update Active Organization Member

A member row joined to the identity behind it, as the roster shows it.

Field-for-field the platform's shape, so the ported roster page is not rewritten around a new contract, with two consequences of the OSS line: email is nullable here (a local operator identity has no sign-in address), and invitation_id is always null until the invitation flow rehomes, which is what fills it.

attribution_user_id is the addition the platform has no counterpart for. Keys, budgets, and usage attach to the gateway's string-keyed users row, not to this UUID identity, so this carries the user_id a caller passes to POST /v1/keys to give this member a key. It is null when no usable row exists (nobody minted one, or it was soft-deleted through DELETE /v1/users), which is the signal not to offer this member as a key owner: key creation would refuse. How the two ids converge is the open question in otari-ai#1727; this field is the join until it is answered, and is what lets either answer land without the dashboard changing.