wallet: reorganize internal db and sql package layout

[yyforyongyu]

Summary

wallet/internal/db currently mixes several concerns in one flat area:

• public DB contracts and shared types
• handwritten backend implementations
• generated sqlc output
• handwritten SQL queries and migrations
• integration tests and helper code

This makes ownership and navigation harder than necessary, especially as the SQL store grows.

Proposal

Reorganize the layout so responsibilities are separated more clearly:

wallet/internal/
  db/
    errors.go
    interfaces.go
    <split public type files>
    common/
    postgres/
    sqlite/
    kvdb/
    itest/

  sql/
    postgres/
      migrations/
      queries/
      sqlc/
    sqlite/
      migrations/
      queries/
      sqlc/

Intended boundaries

• wallet/internal/db/
  • public contract layer for the SQL-backed DB package
  • shared types, errors, and store interfaces
• wallet/internal/db/postgres and wallet/internal/db/sqlite
  • handwritten backend-specific Go implementations
• wallet/internal/db/common
  • small backend-agnostic handwritten helpers only
• wallet/internal/sql/...
  • SQL assets only
  • handwritten migrations and queries
  • generated sqlc output

Goals

• make wallet/internal/db the public-facing API layer
• separate handwritten Go, handwritten SQL, and generated code
• keep postgres and sqlite assets grouped by backend
• make feature ownership and navigation easier
• make future SQL store growth less painful

Non-goals

• no behavior changes
• no schema changes
• no wallet policy changes
• no broad API redesign beyond what is needed to avoid import cycles

Notes

One important consequence is that constructors may need to live in backend packages such as:

• wallet/internal/db/postgres
• wallet/internal/db/sqlite
• wallet/internal/db/kvdb

rather than the top-level wallet/internal/db package, in order to avoid import cycles once db/ becomes the contract layer.

Migration plan

A reasonable order would be:

1. split data_types.go into domain-specific type files
2. split interface.go into interface and error files
3. move SQL assets into wallet/internal/sql/...
4. move generated sqlc output into backend-local sqlc/ directories
5. move handwritten backend implementations into wallet/internal/db/postgres and wallet/internal/db/sqlite
6. rename large feature files to align with responsibilities (for example, tx_replacements_* -> txgraph.go)

Risks / things to watch

• import cycles between db and backend packages
• sqlc.yaml output path changes
• Makefile path updates
• test/package visibility changes
• large diff churn if attempted all at once

This issue is intended as the design/coordination anchor before any large file-move refactor.

[yyforyongyu]

Given that each of the files can also be large, like db/sqlite/tx.go, it makes more sense to break each file by methods on the store interfaces, so we have,

• db/sqlite/tx_store_createtx.go
• db/sqlite/tx_store_deletetx.go
• ...