bug: table catalog is not updated correctly during recovery

[zwang28]

Describe the bug

etcd meta backend

1. inject failure to trigger recovery
2. trigger recovery

create table t(k int primary key, v int);
create table t2(k int primary key, v int);
create sink sk into t as select * from t2;
flush;
create sink sk2 into t as select * from t2;
flush;
create sink sk3 into t as select * from t2;
flush;
--- trigger injected panic. however sk4 is created successfully.
create sink sk4 into t as select * from t2;
--- after the cluster recover
--- fail: Streaming vnode mapping not found for fragment
insert into t values (1,1),(2,2);

3. the fragment_id and dml_fragment_id of table t is outdated (corresponding to the version after sink sk3), which is inconsistent with select * from rw_fragments where table_id = xxx (corresponding to the version after sink sk4).
4. sk4 is not in table t's incoming_sink, but sk4 fragment exists even after recovery.

Error message/log

No response

To Reproduce

No response

Expected behavior

No response

How did you deploy RisingWave?

No response

The version of RisingWave

No response

Additional context

No response

[zwang28]

@yezizp2012

I haven't confirmed whether the SQL meta backend is also affected by this issue.