CLI contexts can still trap on the missing CodexBarCore resource bundle (JS-plugin providers)

## Summary Follow-up to #2738: the packaged app is fixed (`9c5658372`), but CLI contexts still have the same latent trap. Neither the app's `Contents/Helpers/CodexBarCLI` directory nor the standalone `CodexBarCLI-v0.48.1-macos-*.tar.gz` artifacts ship `CodexBar_CodexBarCore.bundle` — verified against the released 0.48.1 assets. `CodexBarCoreResources.resolve` falls through to raw `Bundle.module` outside an `.app` context, whose accessor probes only executable-adjacent and the compile-time build path, then traps. Since 0.48.0 defaults six providers (Crof, Venice, OpenRouter, ClawRouter, Deepgram, sub2api) to bundled JS plugins on macOS, any CLI invocation that constructs a plugin runtime for those providers on a user machine should hit the fatal — masked on dev machines by the baked-in build path, exactly like #2738 was. ## Fix sketch (agreed direction) 1. `CodexBarCoreResources` grows a non-trapping resolution for executable contexts: probe app Resources, then executable-adjacent `CodexBar_CodexBarCore.bundle`, then SwiftPM build-dir candidates via explicit FileManager existence checks; only touch `Bundle.module` when one of its candidate paths exists; otherwise return nil and let plugin call sites throw `ProviderPluginError.load` (a clean provider error, not a process trap). 2. Ship the bundle: `package_app.sh` places it next to `Contents/Helpers/CodexBarCLI`; the CLI tarball packaging adds it alongside the binary. 3. Extend #2755's resource smoke probe to cover the CLI binary in both artifact shapes. Refs #2738, #2755.