fix(admin): block default product variant routes without patching Medusa

[wasin-creator]

Summary

• Replaces the startup-time Medusa node_modules patch for default admin product-variant routes with a Mercur admin middleware blocker.
• Switches the generated API app scripts to call Medusa CLI directly for build/dev/start.
• Keeps dev-time codegen working from generated apps by finding the nearest workspace lockfile before choosing bunx/pnpm/yarn/npx.

Closes #993

Details

• Adds a 404 blocker for /admin/product-variants* in @mercurjs/core admin middleware.
• Removes patchMedusa() from mercurjs start.
• Leaves /admin/products* untouched because Mercur owns packages/core/src/api/admin/products/route.ts; blocking that matcher needs a separate route matrix to avoid shadowing Mercur's replacement route.

Verification

• RED: bun run test:integration:http -- admin/default-medusa-product-routes failed before the blocker with expected 404 / received 403 after rebuilding core from main source.
• GREEN: bun run test:integration:http -- admin/default-medusa-product-routes passes.
• bun run build passes: 10 successful / 10 total.
• cd apps/api && bun run dev starts on port 9000; /health returns HTTP 200; no Codegen failed / command-not-found logs.
• cd apps/api && NODE_ENV=production bun run start starts on port 9000; /health returns HTTP 200; no patch/command errors.

Follow-up

• Decide the exact /admin/products* route matrix separately before replacing the remaining product-route patch behavior, because Mercur already provides its own admin products route.

[wasin-creator]

Update after route-loader investigation:

This PR should be treated as not ready to merge as-is.

The original goal was to remove patchMedusa() from mercurjs start by replacing the route-disabling behavior with Mercur-level middleware/route mechanisms. Spikes confirmed that only /admin/product-variants* can be blocked this way.

For /admin/products/**, official Medusa v2 route-loader behavior explains why the replacement does not work:

• API layers are registered in order: Core → Plugins → Application.
• Core route middlewares/policies run before plugin/app middlewares.
• Exact-path core route handlers cannot be cleanly shadowed by plugin/app route handlers.
• The supported pattern is "Replicate, Don't Override" under a new route path, not overriding core admin routes in place.

Spike results:

• Mercur middleware blocker: works for /admin/product-variants*, not nested /admin/products/**.
• Plugin products/middlewares.ts override: generated, but did not disable Medusa core product policies.
• Generated disabled route stubs: generated, but Medusa core product handlers still executed.

Conclusion: full removal of patchMedusa() is blocked unless Medusa provides an official core-route disable hook or Mercur keeps a scoped patch for /admin/products/**.

Recommended next step: keep PR #992 as the production-safe fix and either close/rework this PR so it does not remove patchMedusa() from start.

[wasin-creator]

Closing this PR as not ready after the route-loader investigation.\n\nThe safe production path remains PR #992: use native Medusa CLI for dev/build while keeping on so still preserves the existing admin product route-disabling behavior.\n\nFull removal of is blocked for by Medusa v2 route-loader precedence. Details are documented in issue #993.

[wasin-creator]

Correction to the previous close comment (shell quoting stripped inline code):

Closing this PR as not ready after the route-loader investigation.

The safe production path remains PR #992: use native Medusa CLI for dev/build while keeping start on mercurjs start so patchMedusa() still preserves the existing admin product route-disabling behavior.

Full removal of patchMedusa() is blocked for /admin/products/** by Medusa v2 route-loader precedence. Details are documented in issue #993.