…ive (#10180)

Stacked on #10168.

### What

Adds `TopLevelImportReadDetector` — a dedicated, uniform AST walk that
marks a top-level statement as execution-order sensitive when its
module-evaluation-time execution reads an imported binding — and OR-es
it into `EcmaViewMeta::ExecutionOrderSensitive`.

### Why

On-demand wrapping should eventually decide "wrap or not" from
execution-order sensitivity alone, so that a module which imports
dependencies but only uses them inside function/class bodies can stay
unwrapped. For that, the order-sensitivity signal must be **complete**:
it may never miss a top-level read of an imported binding, or such a
module could be unwrapped and reordered across a mutation.

The earlier approach (#10169) threaded this fact through the
per-expression-form side-effect analyzer, which is exactly how gaps slip
in — e.g. an imported binding in a mid-chain computed key (`a[imp].y`)
or a namespace aliased into a local (`const x = ns; x.foo`). This
replaces that with a single uniform walk that visits every sub-node
once, so no expression form can be missed and newly added syntax is
covered by default. It is a deliberate over-approximation, which is the
sound direction for wrapping (under-reporting is the only dangerous
mistake).

Skipped, and why each stays sound:

- **Function / arrow bodies** (incl. class method bodies and parameter
defaults) run at call time. If such a body runs during module evaluation
it does so through a call / `new`, which the side-effect /
pure-annotation analysis already reports as order-sensitive.
- **Import declarations and re-export specifiers** (`export { a }`,
`export { a } from '...'`) forward bindings without reading a value, so
pure barrels stay unmarked.
- **Type annotations** are erased at runtime.

Known limitation, inherent to any syntactic analysis: under
`treeshake.propertyReadSideEffects: false`, a getter / `Proxy` trap that
reads an imported binding is invisible here — that is the option's own
"reads are side-effect-free" promise, not a gap this walk can close.

### Currently inert

Every unwrap / chunk-grouping consumer of `ExecutionOrderSensitive` is
additionally gated by `import_records.is_empty()`, and a module that
reads an import necessarily has an import record, so no wrap or chunk
decision changes yet. This lands the detection ahead of the follow-up
that drops the `import_records.is_empty()` gate and lets the flag decide
unwrapping on its own.

### Tests

- `cargo test -p rolldown --lib top_level_import_read` — 6 new unit
tests: direct / member / computed-key / compound reads; the `a[key].y`
mid-chain computed-key and `const x = ns; x.foo` namespace-alias cases;
function / arrow / method bodies skipped; re-export barrels and locals
not flagged; static field initializer and `extends` clause.
- `cargo fmt --check` and `cargo clippy -p rolldown --lib --tests`
clean.
- Full integration suite unchanged — the change is inert; the
strict-execution-order / wrapping / on-demand fixtures are green.