feat(flutter): SEP-10 wallet sign-in before a real hire (signChallenge with challenge checks, session on the Serverpod client)

[XxHugheadxX]

Refs #136

The app half of wallet-authenticated sessions. The server half is #147.

Summary

Since #147, the server accepts hire calls only from a wallet-bound session. The app connected Freighter and read the address, but never signed in, so with HIRE=server every hire ended in "Sign-in with your wallet is not available yet". It also could not sign the challenge: FreighterWallet.signTransaction requires every source to be the connected account (#69), and a SEP-10 challenge's source is the server.

Wallet

• WalletPort.signChallenge(SignInChallenge). The Freighter adapter validates the challenge with assertSep10Challenge before any prompt:
  • sequence number 0, so the challenge can never be submitted;
  • only manage_data operations;
  • the first one is <home domain> auth, from the connected account;
  • every other operation comes from the server (the transaction source), which is never the connected account;
  • time bounds that include now;
  • when known (config.json auth), the server signing key and the home domain.
• After signing, the body must be unchanged and carry a new signature from the connected account. signTransaction uses the same check.
• MockWallet and WalletController implement it.

Session

• WalletSession runs createChallenge, then the wallet signature, then verifyChallenge. The AuthSuccess is stored by the client's FlutterAuthSessionManager, which sends it on every call.
• A session is reused only for the wallet that opened it. A challenge issued for another wallet is never signed.
• main.dart sets client.authSessionManager. It reads serverSigningKey and homeDomain from config.json auth when the server publishes them. The bundled config of the Pages build has no auth; the wallet checks still hold without it.

Hire flow

• HireGateway.ensureSignedIn / forgetSession. Both do nothing in the demo.
• When it signs in: after connecting and before createHire, in the new step signingIn ("Sign in with your wallet: it only proves the account is yours").
• Refused session: when the server rejects the session (NotAuthenticated, AuthenticationUnavailable), or rejects the sign-in (ChallengeExpired, ChallengeConsumed, ChallengeNotFound, InvalidWalletSignature → HireSignInFailed), the session is dropped, so Try again signs in afresh.
• ChallengeRateLimited: "too many sign-in attempts".

Acceptance criteria (#136, app half)

• The app signs in through walletAuth.createChallenge / verifyChallenge, and the session is sent on every call.
• The wallet signs only a valid SEP-10 challenge for its own account (10 guards, each tested).
• A refused or expired session is dropped and redone on retry.
• Live run with Freighter against the deployed server. Blocked: the deployed API (1.0.0+4df3ba4) returns 404 for walletAuth and hire until it is redeployed from main (chore: deploy server to Serverpod Cloud and Flutter web app #31).

Verification evidence

$ cd puls3_flutter && flutter analyze --fatal-infos
No issues found!
$ flutter test
00:32 +267: All tests passed!
$ flutter build web --release
√ Built build\web

New tests:

• test/wallet/freighter_wallet_test.dart, group signChallenge:
  • challenges are built like the server's StellarSep10Codec and signed by a real key through the fake Freighter bridge;
  • a valid challenge, with and without the server key;
  • signTransaction refuses it, which is why this path exists;
  • every refusal: sequence ≠ 0, the wallet as source, a non-manage_data operation, another account, another operation source, a wrong home domain, another server key, no or expired time bounds, the wrong network, a changed answer, no new signature.
• test/hire/wallet_session_test.dart:
  • sign-in order;
  • reuse for the same wallet;
  • a wallet switch;
  • a restored session for an unknown wallet;
  • a challenge for another wallet;
  • a declined signature;
  • a refused verification;
  • forget;
  • the gateway's error mapping.
• test/screens/hire_sheet_test.dart:
  • sign-in happens before createHire;
  • a declined sign-in creates no hire, and a retry works;
  • a refused sign-in is dropped and redone.
• test/data/app_config_test.dart: readAuthConfig.

I broke each guard one at a time to check that the tests catch it. All 10 changes made a test fail:

• sequence 0;
• only manage_data;
• the challenge's account;
• the source of the second operation;
• expiry;
• the server key;
• a challenge for another wallet;
• reusing another wallet's session;
• no sign-in before the hire;
• not dropping a refused session.

Notes for reviewers

• The session lives in memory. The wallet that opened it is not persisted, so after a reload the first hire signs in again (one extra Freighter prompt). Persisting it would need flutter_secure_storage as a direct dependency, which I left out.
• Not in this PR: the default stays HIRE=demo. Flipping it and redeploying the server (chore: deploy server to Serverpod Cloud and Flutter web app #31) are what make the real flow live; see the demo analysis on feat: wallet-authenticated sessions (challenge sign-in) for server and app #136.

[cloudflare-workers-and-pages]

Deploying puls3 with    Cloudflare Pages

Latest commit:	f07f76e
Status:	✅  Deploy successful!
Preview URL:	https://03337bbc.puls3-4lw.pages.dev
Branch Preview URL:	https://feat-136-app-wallet-sign-in.puls3-4lw.pages.dev

View logs

[moises-cisneros]

Note for testing this end to end: with a real funded testnet account, sign-in will fail on the server, independent of this PR. The signer lookup cannot decode a real account entry, so verifyChallenge answers AuthenticationUnavailable and the app shows "Sign-in with your wallet is not available yet".

I reproduced it by signing a challenge directly against the server with a funded account, with no Flutter code involved. The fix is in #158 (server only). Once it is merged, this PR should work with a real Freighter account.