Add an optional Git handle flow. Collection of the information and its processing must remain optional.

In the existing flow to add a member:

0. Ask users if they want to link a Git handle to their account.

1. If yes, collect the following. Else do nothing.
   a. Git handle: <provider>:<username> (e.g. github:alice).
   b. Ed25519 public key registered on that Git account (auto-fetched or pasted). Support GitHub and Gitlab a minima, e.g. on GitHub we can do https://github.com/<username>.keys.
   c. Build a SEP-53 envelope (five newline-separated lines):

   Stellar Signed Message
   <network-passphrase>
   <signing-account>            # we use the contract invoker address
   <16-byte random nonce hex>
   tansu-bind|<contractId>|<gitId>
   

   • The last line is the domain-separated payload that encodes the Git handle.
   • Nothing is signed yet.

2. Git-side signature
   • UI shows the ready-made command (SSH or GPG) that signs the full envelope with the chosen Git key.
   – SSH example: ssh-keygen -Y sign -f <privateKey> <(echo -n "<challenge>")
   – GPG example: printf "%s" "<challenge>" | gpg --clear-sign --detach-sig --armor
   • User pastes the signature; browser verifies it against the supplied public key ed25519_verify(pubkey, msg, sig).
   • Success enables Join.

3. Assemble the add_member call (still no wallet prompt)

   meta          // existing profile field
   git_identity  // <provider>:<username>
   git_pubkey    // Ed25519 key proven in step 2
   msg           // exact SEP-53 envelope from step 1
   sig           // Git-side signature from step 2
   

4. Single wallet signature
   • Dapp constructs the transaction, embeds the five fields above, then calls signTransaction.
   • One wallet popup; user approves.

5. Broadcast & on-chain checks (inside add_member)
   • Contract verifies:
   – ed25519_verify(invoker, msg, sig) — Git proof.
   – Envelope header equals “Stellar Signed Message”.
   – network line equals env.network_passphrase().
   – account line equals invoker.
   – nonce is 32 hex chars (optionally ensure one-time use).
   – payload starts with tansu-bind|.
   • If all pass, it stores git_identity, git_pubkey, msg, sig, and signed_at.

6. Member profile shows the Git username and mark it as verified. If we do not have a Git handle registered say that the user did not link one.

Outcome (unchanged UX)

• User signs once with their Git key (CLI) and once with their wallet.
• Registration and Git-ID binding land in a single Soroban transaction.
• Proof format follows SEP-53 message-signature standard.