Refactor: expose only signBytes for implementation

[AlexKushnir1]

Pre-flight checklist

• I have read the Contributing Guidelines on pull requests.
• Commit messages follow the conventional commits spec
• If this is a code change: I have written unit tests.
• If this changes code in a published package: I have run pnpm changeset to create a changeset JSON document appropriate for this change.
• If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

Motivation

Provide abstract class Signer that has only two methods to implement signBytes and getPublickKey, while implementing many signature methods. That way, the flow stays consistent, and users only focus on the actual signing step

Test Plan

Added unit tests to verify the correctness of the NEP-413 payload hash generation and signature logic:

• Hash Generation Test
• Signature Verification Test

[changeset-bot]

🦋 Changeset detected

Latest commit: 773491e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 15 packages

Name	Type
@near-js/signers	Major
@near-js/cookbook	Major
@near-js/accounts	Major
@near-js/biometric-ed25519	Major
@near-js/client	Major
@near-js/crypto	Major
@near-js/iframe-rpc	Major
@near-js/keystores-browser	Major
@near-js/keystores-node	Major
@near-js/keystores	Major
@near-js/providers	Major
@near-js/tokens	Major
@near-js/transactions	Major
@near-js/types	Major
@near-js/utils	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[denbite]

@AlexKushnir1 I agree with the idea that end users shouldn't handle signature verification themselves, yet the current approach still leaves room for mistakes, like forgetting to call getPayloadHashForNEP413 inside signNep413Message

one alternative could be to move all the logic into the abstract Signer class and expose just a protected signMessagePayload(bytes: Uint8Array) method for end users to implement - that way, the flow stays consistent, and users only focus on the actual signing step

[AlexKushnir1]

Hey @denbite! Thanks for pointing out that inaccuracy — it's been fixed. I hope this is the kind of solution you had in mind!

[AlexKushnir1]

@denbite I add state as param.callBackUrl, is that expected logic?

[denbite]

according to the NEP doc, a browser wallet should pass the state parameter as a query parameter in the callbackUrl, so we need to parse it out of callbackUrl and return it to a user if present

[AlexKushnir1]

IMO it works as it should now.
Previosly the state was just ignored:

return {
    accountId: accountId,
    publicKey: pk,
    signature: signature,
};

[denbite]

according to the NEP doc, a browser wallet should pass the state parameter as a query parameter in the callbackUrl, so we need to parse it out of callbackUrl and return it to a user if present