Two related bugs surfaced when the user tried adding `setup({...})` to
their init.lua alongside our auto-setup:
1. **`inmemory.bps = nil` crash.** When a user's `init.lua` does
`vim.pack.add(..., turbo-debug)` and then calls `setup({...})`
synchronously right after, the nested `vim.pack.add` calls inside
our own `plugin/turbo-debug.lua` (for dap/dapui/persistent-
breakpoints) are DEFERRED by nvim's pack module — so the user's
follow-up `require('persistent-breakpoints')` throws "module not
found". On the previous `initialized = true` guard, the error set
the flag but left setup half-complete; any later call short-
circuited and `inmemory.bps` stayed `nil`, exploding the first
breakpoint toggle (`api.lua:15: attempt to index field 'bps'`).
2. **Colorscheme override ignored.** Same root cause: user's
`setup({ colorscheme = "nightfox" })` errored before reaching
`config.merge`, so `config.opts.colorscheme` stayed `nil` and
`M.enter` never switched themes.
Three changes that together fix both:
- **`init.lua` `setup()` self-defers** when `require('persistent-
breakpoints')` fails, `vim.schedule`s itself once deps can load.
- **`plugin/turbo-debug.lua` auto-setup is now `vim.schedule`d** and
skips entirely if the user's explicit `setup({...})` already ran
(tracked via `M._setup_called`) — no more stomping user opts with
a second `config.merge(nil)`.
- **`breakpoints.setup` is now fully idempotent**: dropped the
`initialized` flag, since every call inside it
(`persistent-breakpoints.setup`, `sign_define`, `nvim_set_hl`,
`vim.keymap.set`) is safe to re-run.
swaits
7a21d372ff