fix(build): resolve @stacksjs/actions subpath when compiling the CLI

[glennmichael123]

Closes #2242. Takes compile green — the last of main's three red CI jobs after #2223 (typecheck) and this.

The fix

One paths entry:

"@stacksjs/actions/*": ["./actions/src/*"],

@stacksjs/* binds the wildcard to the whole remainder, so @stacksjs/actions/blog looked for ./actions/blog/src, missed, and fell back to actions/dist/blog.js. Nothing builds workspace packages before the compile job, so:

error: Could not resolve: "@stacksjs/actions/blog"
  at core/buddy/src/production-server.ts:370:53

Why this was reverted once, and why it is safe now

This is the same entry I added in #2223 and then removed, because it appeared to turn core/config and core/env tests red. It did not.

That was the load-order race in the config overrides fallback, fixed in #2246: defaultsForOverrides() omitted app.url, so expect(typeof app.url).toBe('string') passed or failed on whether the async config load won. This entry perturbed module resolution enough to expose it — which is exactly how a package.json dependency in #2244 also managed to "break" the same two packages. Two changes with nothing in common except that they moved resolution around; that was the signature I misread as "the tsconfig entry is at fault".

With #2246 on main:

• core/config + core/env with this applied: 322 pass, 0 fail
• CLI compile: bundles 1933 modules and links

Note on scope

Only @stacksjs/actions/*. The browser / composables / desktop-build entries stay in core/tsconfig.json where they fix typecheck; this file is extended by most core/* package tsconfigs, so it governs bun test resolution too and deserves the narrower footprint. That asymmetry is commented in both files.