refactor: introduce Client type, remove TUI from library, eliminate init() side effects

[zeroshade]

Summary

This branch refactors the dbc package from a package-global, init()-heavy design to a clean library API:

• New Client type with functional options (WithHTTPClient, WithRegistries, WithBaseURL, WithUserAgent, WithCredential, WithAuthFromFilesystem) replacing package-level singletons
• TUI dependencies removed from root dbc and config packages — import "github.com/columnar-tech/dbc" now pulls zero bubbletea/lipgloss/bubbles transitive deps; widgets moved to cmd/dbc
• init() side effects eliminated — no disk writes, no http.DefaultClient mutation at import time; lazy sync.Once-based setup only triggered on first network call
• Old APIs deprecated (GetDriverList, DefaultClient) with forwarding shims for backward compatibility; CLI migrated to use Client internally
• 27 iterative fix commits addressing resource leaks, nil panics, race conditions, double-closes, and request-reuse violations surfaced by automated branch review

New Client API

c, err := dbc.NewClient(
    dbc.WithBaseURL("https://my-registry.example.com"),
    dbc.WithHTTPClient(myHTTPClient),
)
drivers, err := c.Search("adbc-driver-")
manifest, err := c.Install(cfg, "adbc-driver-postgresql")

Testing

All tests pass (go test ./...). Branch reviewed and passed by automated code review (27 commits, roborev job 1027).

[amoeba]

Since this is too big to review in a reasonable amount of time, I just thought about the downstream use cases a bit.

This seems like the right direction to start moving but there'd still be quite a bit of work to make dbc loadable as a C extension. Which I assume is part of the purpose here. Stuff like exports, FFI-compatible types, etc.

The new Client interface with the Option pattern for customizing seems pretty reasonable. I'm not too familiar with Go but if we think the pattern is the most familiar than that works for me. One thing I found was my LSP wasn't super helpful with this pattern,

Here, it lists three of the candidates but not all,

I had to assume all of them were prefixed with With:

Any idea if there's a way to improve on this or if a different pattern works better with the Go LS?

[zeroshade]

This seems like the right direction to start moving but there'd still be quite a bit of work to make dbc loadable as a C extension. Which I assume is part of the purpose here. Stuff like exports, FFI-compatible types, etc.

For now, the purpose here is solely to make dbc useful to be imported by other Go programs instead of having to call out to it by spawning another process. I wasn't planning on going as far as trying to make it loadable as a C extension until there's an explicit request for that.

The new Client interface with the Option pattern for customizing seems pretty reasonable. I'm not too familiar with Go but if we think the pattern is the most familiar than that works for me. One thing I found was my LSP wasn't super helpful with this pattern,

The Option pattern is common for Go and a familiar way to manage this. Though I'm surprised your LSP was having an issue. Are you using gopls?

[zeroshade]

@copilot resolve the merge conflicts in this pull request

[amoeba]

I'm using the default editor extension in either VSCode or Zed which I assume is both gopls based. Do you see something different?

[Copilot]

@copilot resolve the merge conflicts in this pull request

Done. Applied the workflow security improvements from main (zizmor fixes: SHA pinning, persist-credentials: false, permission scoping, pull_request vs pull_request_target, template injection safety) in commit 6033586.

[zeroshade]

Interesting, I see the same thing you are. That's odd, though i don't need to assume the With, if i just type "dbc." then the LS finds all the options. I don't think there's anything we can really do to make that better, as far as I'm aware at least

[amoeba]

Thanks for checking.