Add Svelte adapter for invisible-wallet-sdk

[Muhammadcodes112]

Adds a Svelte adapter and SvelteKit example.

• Add @veil/invisible-wallet-svelte (sdk/svelte): a writable store wrapping the framework-agnostic invisible-wallet-sdk/vanilla core, exposing register/deploy/login/sign/send helpers and a reactive { status, walletAddress, error } store. Add a SvelteKit example (examples/sveltekit) with register, dashboard, and send routes, and document the adapter in the top-level README.

Closes #174

[vercel]

Someone is attempting to deploy a commit to the miracle656's projects Team on Vercel.

A member of the Team first needs to authorize it.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
33210559	Triggered	Generic Password	19ba67f	examples/sveltekit/src/lib/network.ts	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[Muhammadcodes112]

Good day maintainer
i believe its all fine now, Pls review

[Miracle656]

Reviewed and holding this open on one blocker, which I can't clear myself.

Blocker: GitGuardian

GitGuardian Security Checks reports 1 secret uncovered! on 19ba67f. That's a hard merge gate on this repo, so nothing lands until it's resolved.

I searched for it and could not find a committed credential:

• no literal secret in git diff main... for this branch
• no S… seed, JWT, sk-/gh*_ token, AWS key or PEM block anywhere in the added lines
• the only matches on secret-shaped patterns are identifier names and a storage key, not values:

localStorage.setItem('veil_fee_payer_secret', feePayer.secret());
let feePayerSecret: string | null = null;
await wallet.deploy(feePayerSecret);

My guess is a generic high-entropy or "secret assignment" heuristic firing on setItem('veil_fee_payer_secret', …), but that's a guess — the finding detail is only visible on the GitGuardian dashboard, and because this PR comes from a fork GitGuardian can't associate it with an incident there either. @Miracle656 will need to look at the finding directly and either dismiss it or tell us what it caught.

For context: your earlier #191 targeted the same issue and reported the identical GitGuardian failure, so whatever it is, it predates this branch's specific contents. I closed #191 in favour of this one — it was CONFLICTING, deleted 283 lines of the root README (including the # Veil title, code fences and ADR links), and carried an 855→1209 line refactor of useInvisibleWallet.ts unrelated to #174. This PR avoids all of that: MERGEABLE, README change purely additive (+22/-0), no lockfiles.

The code itself

Reads well. sdk/svelte/src/index.ts uses a writable store of { status, walletAddress, error } exactly as #174 asks, examples/sveltekit/src/lib/network.ts resolves everything from $env/static/public with a documented .env.example, and the three routes (register / dashboard / send) demonstrate DI without pulling React in — so "No React dependency in the Svelte bundle" holds.

One thing worth changing regardless of the GitGuardian outcome: the example persists the fee-payer secret in localStorage, which is readable by any script on the origin. For a demo that's arguably acceptable, but it's worth a comment in the example saying so explicitly, since people copy example code. sessionStorage at minimum, or an in-memory store with a note that production wallets should use a non-extractable key.

Leaving this open rather than closing — the work is sound and it should merge once the security check is cleared.

[Muhammadcodes112]

Okay I will fix it soon

[Muhammadcodes112]

Hello maintainer
Plz review