docs: simplify the email signature guide

[Cre-eD]

Why

New API users get stuck on the signature field of the authorization request. The signing tutorial presented it as an SDK-specific operation, and its JavaScript example printed the signature of the unhashed email address, so anyone comparing their own output against the documented one concludes their implementation is broken.

What changed

Signing user email addresses rewritten:

• States the construction up front: signature = Hex( Ed25519-Sign( authPrivateKey, BLAKE2b-256( UTF-8(email) ) ) ).
• Leads with Python and Node.js examples that need one common dependency each, no blockchain SDK. Both were executed as written and return the documented signature.
• Keeps a Kotlin/Java example and notes that the SDK hashes the payload internally, which is why it receives the email address as raw bytes.
• Replaces the incorrect example output with a verified one, and adds a test vector (public example data) so an implementation can be checked before it is pointed at the API.
• Adds the two things that most often cause a 422: signing with the Blockchain key pair instead of the Authorization one, and passing a 128-character private key.

Authorizing an account: notes that signature and authPublicKeyHex must come from the same Authorization key pair.

Web App UI: notes that a 128-character private key on the Profile screen is the private key followed by the public key, and that only the first 64 characters are the private key.

Calling API endpoints: points users who only need to upload, flag or download data at the Web App, which requires no code.

Verification

• pnpm docs:build, pnpm format:check and pnpm lint pass locally.
• Python and Node.js snippets extracted verbatim from the page and executed: both return 57e711...e630a, matching the test vector and the documented output.