[Bug]: INSERT into a partitioned table with a FULLTEXT index panics in disttae Write

### MatrixOne version

`4fdb9e91615f9fc37703039ae28a47849206d1d6` (latest main when reproduced), Linux/amd64 standalone launch deployment.

### What happened?

DDL permits a FULLTEXT index on a partitioned table, but inserting rows fails with an internal panic:

```text
panic BUG: cannot write data to partition primary table
pkg/vm/engine/disttae.(*combinedTxnTable).Write
pkg/vm/engine/disttae.(*txnTableDelegate).Write
pkg/sql/colexec/insert.(*Insert).insert_table
```

This was found as an adjacent counterexample while validating #28309/#28310. Those changes affect DELETE scope only and do not touch INSERT planning or execution.

### Reproduction

```sql
drop database if exists partition_fulltext_insert;
create database partition_fulltext_insert;
use partition_fulltext_insert;

create table p(
id int primary key,
body text,
fulltext ft(body)
) partition by hash(id) partitions 2;

insert into p values
(1, 'odd token'),
(2, 'even token'),
(3, 'odd three');
```

### Actual behavior

The INSERT returns error 20101 with the panic stack above.

### Expected behavior

Either:

1. DDL rejects the unsupported partitioned-table/FULLTEXT combination before it becomes usable, or
2. insert/index maintenance routes base rows to physical partitions and maintains FULLTEXT entries without writing to the logical partition-primary table.

No accepted DDL/data path should reach a `panic BUG` for ordinary SQL.

### Root-cause direction

The index-maintenance branch appears to retain or reconstruct an origin-table write target that resolves to the logical partition primary table. Audit INSERT/ODKU/REPLACE/UPDATE/DELETE for synchronous and async FULLTEXT variants, including rollback and multi-row batches, rather than adding a one-statement guard.