feat: refactor service classes

[digitalSloth]

Uniform service-layer architecture: ChainService base + Tier-B convention

Summary

Makes the src/core/ service layer architecturally uniform before we add unit tests. Previously the services shared a singleton pattern but diverged in constructor shape; the planned test-friendly refactor would have left them in three different shapes. This collapses that inconsistency into a documented two-tier convention.

• Tier A — chain services: the 7 blockchain services share one base (ChainService) and one DI seam (an injected ZenonService).
• Tier B — everything else: services with genuinely different dependencies follow one documented rule — public constructor injecting its own deps, defaulted to the production wiring; the singleton/module-const is just the prod wrapper.

Net result: −43 lines (56 insertions / 99 deletions), no behavior change, and every service is now constructable with fakes for the upcoming test suite.

Changes

1. Add ChainService abstract base
New src/core/chain-service.ts — protected zenon, a public constructor injecting ZenonService (defaulted to the prod singleton), and ensureInitialized(). The ctor is public so subclasses stay test-constructable; abstract is what prevents direct instantiation.

2. Migrate the 7 network services onto it
account / transaction / stake / plasma / pillar / rewards / token now extends ChainService, dropping their duplicated zenon/zenonService fields, private constructor, and ensureInitialized(). Each keeps its own static instance + getInstance() (deliberately not hoisted, to avoid a TS strict static-typing pitfall). No RPC method body changed.

3. WalletService Tier-B ctor + document the convention

• wallet-service.ts: public defaulted-DI ctor (constructor(private storage: StorageAdapter = storageService)); getInstance() wiring unchanged.
• Comment-only docs of the two-tier rule in chain-service.ts (canonical home) plus one-line pointers on session-manager.ts and storage-service.ts.

Behavior preservation

Fully behavior-preserving. Each service's getInstance() still returns the same singleton wired to the same ZenonService/storageService; the defaulted ctor params reproduce the previous explicit wiring exactly. No composable, background.ts, main.ts, or src/core/index.ts was touched — the ~16 getInstance() call sites are unchanged.

Out of scope

ZenonService (the injected dependency itself), PlasmaBotService (already self-documents its exemption), SessionManager/StorageService, and the storage adapters are intentionally left as-is under the Tier-B convention. No tests are added here — that's the follow-up.

Verification

• npm run typecheck — 0 errors
• npm run lint — 0 errors (6 pre-existing warnings)
• npm run build and npm run build:extension — both pass

[0x3639]

Findings

• [P2] src/core/chain-service.ts:25 still types the injected dependency as concrete ZenonService, so plain test fakes are rejected by TypeScript. ZenonService has private members and a private constructor, making it nominally typed. A virtual test module with new AccountService(fakeZenonService) fails with: “missing properties from type 'ZenonService': zenon, isInitialized, initializePromise…” Use a small interface or Pick<ZenonService, 'getZenon' | 'ensureInitialized'> for the constructor type.

Checks

• Reviewed [PR #14](feat: refactor service classes #14) at head e52bcd43617d85910b2bbccb0c61093f479f97af.
• npm run typecheck: passed.
• eslint . under bundled Node 24: passed with 6 existing warnings.
• Web and extension production builds: passed.

No production behavior regression jumped out; the main issue is that the refactor does not fully deliver the claimed fake-injectable service layer yet.

[0x3639]

Looks good to go. No additional comments!

[edgepillar]

Hi — I’m considering a small tests-only follow-up to #14 focused on SessionManager.

Proposed scope:

• add Vitest and replace the placeholder npm test script;
• add deterministic unit tests for unlock and retrieval, selective and global locking, timeout eviction, and filtering expired sessions;
• update the existing documentation that states no automated tests are configured.

The tests would use opaque fake keystore objects. There would be no production-code changes, mnemonic or wallet fixtures, browser-storage tests, or CI workflow changes.

I did not find an open issue, pull request, or public branch implementing this scope. Is anyone already working on the test-suite follow-up mentioned in #14? If not, would this be a useful first PR?

[digitalSloth]

@edgepillar Yes please, that would be great if you want to start working on the unit tests for the repo