feat: implement signet link with loopback and web API

[Hussman256]

Fixes #258. This PR implements the signet link command utilizing a local loopback listener to authorize the deploy key with the web application.

[drips-wave]

@Hussman256 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[vercel]

@Anambraboi-1 is attempting to deploy a commit to the blockchainmaxis-8449's projects Team on Vercel.

A member of the Team first needs to authorize it.

[netlify]

❌ Deploy Preview for stellar-signet failed.

Name	Link
🔨 Latest commit	5493bfb
🔍 Latest deploy log	https://app.netlify.com/projects/stellar-signet/deploys/6a93934e01a1690008bde850

[blockchain-maxis]

Thanks for taking on the command that ties the whole feature together — the end-to-end shape here (resolve identity → loopback listener → open approval → wait for callback → prove ownership → report) is the right flow, and it matches what #258 asks for.

I can't merge it as written, though, for three reasons. None of them is about the quality of the work; two are about decisions the surrounding issues already made.

1. The CLI is a Go module at cli/, not a TypeScript package at apps/cli.

#251 ("Scaffold the cli/ Go module — the @signet/cli binary") is the scaffold every other CLI issue builds on, and #252 and #290 are about building, linting and unit-testing that Go module in CI. There are open PRs already working inside cli/ — the scaffold (#335), identity resolution (#369), the loopback server (#370), the error taxonomy (#358). A TypeScript CLI at apps/cli can't coexist with those; whichever landed second would have to be deleted.

npx @signet/cli link still works in that world — #293 covers the release pipeline that cross-compiles the Go binary and wraps it in an npm package. The npm entry point isn't what decides the implementation language.

2. getSecret() pulls the raw secret key out of the keystore.

This is the specific thing #253 exists to prevent:

Delegating means the Signet CLI never holds secret key material at all — not in memory, argv, logs, or a crash dump [...] Parsing the keystore ourselves would take on key custody for no benefit.

stellar keys show puts the secret into this process's memory, and Keypair.fromSecret(secret) keeps it there for the lifetime of the signing call. The delegated path (stellar tx sign --sign-with-key <identity>) never exposes it, and gets hardware-wallet support for free. This one I'd want fixed regardless of the language question.

3. The loopback callback accepts any caller.

/callback takes token and handle from the query string with nothing tying the request to the session that started it — no state. Any local process, or any page the developer happens to have open, can hit http://localhost:<port>/callback and complete the exchange. That's #256, and #328 is already open against it. Related: #348 covers the Private Network Access preflight the browser will send to a loopback origin.

Also worth knowing: the deploy preview build is failing on this branch (all four Netlify checks are red), so something in the workspace change isn't building.

Leaving this open rather than closing it. If you want to keep going on signet link, the highest-value thing you could take is the same flow inside cli/ on top of #335's scaffold, with signing delegated per #253 — that's a real contribution and the series still needs it. The web-side pieces here (/api/cli/link, the approve page, cli-auth.ts) overlap #354, #364 and #355, so I'd leave those to those PRs.