[Schema] Expose the keypair owner's email and deprecate the legacy user_id field

[jopemachine]

Objective

Give the legacy GraphQL KeyPair type an honest field for the owner's email and deprecate user_id, before BA-7206 changes what the column behind it holds.

Background

BA-7206 consolidates the two owner columns on keypairs into one named user_id holding users.uuid. Its acceptance criteria say "No API field changes — KeyPairNode.user_id and the v2 DTO already carry the uuid." That is true of the v2 stack, and false of the legacy graphene type.

gql_legacy/keypair.py declares user_id = graphene.String() and KeyPair.from_row fills it straight from row.user_id — the String(256) column holding the user's email. The uuid is exposed separately as user = graphene.UUID(). So the legacy type already carries both values, under names that read backwards.

When BA-7206 repoints the column, KeyPair.user_id silently changes from an email address to a uuid. No deprecation, no replacement, no release where a client can see both.

The value is also stale by construction — nothing keeps keypairs.user_id in step with users.email — while the legacy keypair queries already join users and select users.email, so the correct value is in hand.

Acceptance Criteria

• Legacy GraphQL KeyPair gains user_email, sourced from the joined users.email rather than the keypairs copy, with an "Added in" description.
• KeyPair.user_id is deprecated with a reason naming user_email for the email and user for the owner's uuid.
• The GraphQL schema dumps are regenerated.
• No behaviour change for existing clients: user_id keeps returning what it returns today.

Notes

• Lands before BA-7206, which is then free to repoint the column.
• Same shape as the marker's API pairing: ship the replacement, deprecate the old field, change the schema in a later release.
• Roughly 30 lines plus the regenerated dumps.

[jopemachine]

PR: #13611

[jopemachine]

Closing as not planned.

This assumed keypairs.user_id would be repointed from the owner's email to their uuid, which would have changed what the legacy KeyPair.user_id field returns and so needed a deprecation window.

keypairs."user" already carries the owner's uuid as a NOT NULL column behind a validated foreign key, so there is nothing to consolidate — user_id stays the email copy it has always been. Superseded by #13611 being dropped.