…shaking (#8925)

## Summary

When a CJS module conditionally re-exports from multiple sources (e.g., React's `jsx-dev-runtime.js`), the linker previously only followed the first import record. This could lead to incorrect inline const values and incomplete tree-shaking.

This PR:
- Records which import records correspond to `module.exports = require(...)` during scanning, rather than relying on `import_records.first()`
- Follows all CJS re-export targets when building `resolved_exports`
- Tracks conflicting CJS exports when multiple targets provide the same name
- Skips inline const for exports with CJS conflicts, since the runtime value depends on which branch executes
- Uses the recorded import record indices to simplify the tree-shaking bailout heuristic

## Background

```js
// jsx-dev-runtime.js
if (process.env.NODE_ENV === 'production') {
  module.exports = require('./production');   // exports.jsxDEV = void 0
} else {
  module.exports = require('./development');  // exports.jsxDEV = function() {...}
}
```

Previously, `add_exports_for_export_star` used `import_records.first()` to find the re-export target. This meant only the first `require()` target's exports entered `resolved_exports` — the rest were silently dropped. This caused `jsxDEV` to be incorrectly inlined as `void 0`.

## Related issues

- vitejs/vite#21884 — the `void 0` inlining case fixed by this PR
- #8345 (comment) — related discussion on the underlying issue
- vitejs/vite#21843 — related Vite issue, worked around by vitejs/vite#21865 (disabling `inlineConst` for affected packages). This PR fixes the root cause in rolldown so we can reenable `inlineConst` in Vite. cc @sapphi-red

## Test plan

- [x] New `inline_const_cjs_reexport` - validates inline const works with multiple cjs re-exports
- [x] New `tree_shaking/cjs_reexport_conditional` — validates ESM+CJS mixed re-export (ESM first, CJS second)
- [x] `just test-rust` all green