feat(wallet): add host-owned default profile lifecycle

[danisharora099]

Outcome

Basecamp modules can use one host-owned LEZ wallet profile without accepting caller-supplied paths. This implements the core portion of #46 while keeping unresolved dependency and live-E2E gates explicit below.

Changes

• derive default/{config,storage,statistics}.json from LogosModuleContext::instancePersistencePath()
• add typed wallet_status, open_default, create_default, and restore_default JSON APIs
• serialize lifecycle and wallet mutations around the single wallet handle
• refuse existing/incomplete profiles and open handles; create the directory exclusively with owner-only permissions
• destroy and roll back incomplete profiles on create/restore/save failures, including a typed rollback failure
• cap restore depth at 10 before filesystem or wallet FFI work because the pinned FFI documents exponential growth
• persist profile/account/label mutations and perform a best-effort save during orderly destruction
• validate generic public submissions before FFI and return {success,tx_hash,secrets,error} on every path, with a non-empty hash required for success
• bump module/runtime metadata to 0.5.0

Verification

• nix build .#unit-tests -L --no-link — 89/89 tests passed; generated LIDL contains 50 methods
• nix build .#lgx -L --no-link — packaged 0.5.0 darwin-arm64-dev LGX successfully
• full runtime doctest against the checked-out PR tree — 25/25 passed, including module load, version 0.5.0, all four lifecycle methods, and generic vector validation
• opt-in real-wallet integration covers create/save/destroy/reopen and second-profile restore with account equality; this target is not run by the current repository CI because it requires an explicitly supplied ../lib

Required follow-up before release

This draft does not claim that #46's full wallet security/release gate is satisfied.

1. The pinned wallet dependency is logos-blockchain/logos-execution-zone commit 15144ddb. In that exact source, create ignores the password, restore also ignores it, and persistent state is written directly as JSON. The serialized structures include the key chain and private account data, including serialized sk and ssk. Encryption at rest remains tracked by logos-execution-zone#156. This PR's owner-only directory is defense in depth, not password encryption.
2. The same dependency prints canonical paths while creating config and saving storage. Lifecycle JSON never returns paths, but dependency log redaction requires a wallet dependency fix and repin.
3. A funded generic public transaction has not yet crossed the generated Basecamp module/RPC boundary. The doctest proves generated vector decoding plus fail-fast validation, and unit tests prove mocked FFI success; the live funded submission required by feat(wallet): own a shared default profile and harden generic transactions #46 remains an explicit environment/release gate.
4. The opt-in real-wallet integration target should be wired into a reproducible CI/runtime environment instead of relying on an unmanaged ../lib.

Refs #46.

[danisharora099]

Funded generated-RPC gate update for exact head d5482868c4706c2de8b931f76f2e1050c219016b:

• Built the checked-out lez_core as an LGX and loaded it through real Logos Basecamp 0.2.2.
• A disposable dependent QML module called the generated lez_core RPC surface; no direct FFI or standalone host was used.
• On a fresh local LEZ v0.2.1 chain, a funded generic public transfer returned the complete success envelope: success=true, a 64-character lowercase transaction hash, empty secrets, and empty error.
• Transaction 8beae84dbb10ed776725eadee6fc28a9e29c2e888abcfef3c404073b4522c2c4 was confirmed in block 7. Source balance moved 150 -> 149 and destination balance 0 -> 1.
• Sixty-two process-topology samples spanning the run retained LogosBasecamp plus logos_host --name lez_core; none contained logos-standalone-app.
• The isolated Basecamp profile/process tree and local chain were removed after verification.

This closes the PR body's item 3 for the generated Basecamp RPC boundary only. It does not close encrypted-at-rest/password enforcement in execution-zone#156, public create/restore onboarding, reproducible real-wallet CI, or release review. The PR should remain draft until those stated gates are resolved, but it is ready for the two required code-owner reviews of the lifecycle/RPC change itself.