RU v2 executor accounting may miss common executors and miscount insert L5 cost

## Bug Report

### 1. Minimal reproduce step (Required)

Run SQL statements whose RU v2 TiDB-side cost depends on executor accounting, for example:

create table t(a int primary key, b int, c int);
insert into t values (1, 2, 3), (2, 3, 4);

create table src(a int primary key, b int, c int);
insert into src values (10, 11, 12), (20, 21, 22);
insert into t(a, b) select a, b from src;

select * from t order by b limit 1;

Then inspect RU v2 statement metrics or the reported RU v2 consumption.

### 2. What did you expect to see? (Required)

RU v2 should count TiDB-side executor work according to the fitted RU v2 model:

- common executors such as projection, sort, TopN, hash join, index lookup joins, select lock, expand, window, and merge join should be mapped to their intended RU v2 executor levels.
- insert L5 accounting should use inserted rows multiplied by inserted column count.

### 3. What did you see instead (Required)

Some executor mappings use stale concrete type strings and may not match current executor package/type names, so those operators can be missed by RU v2 executor accounting.

For insert statements, the L5 metric can be recorded from affected rows instead of RowsColMultiply, which does not match the fitted `executor-l5-insert-rows` model input.

### 4. What is your TiDB version? (Required)

v8.5