[Bug]: updating a HASH partition key to NULL panics in builtInHashPartition

### Description

Updating a nullable HASH partition key to SQL `NULL` triggers a runtime slice-bounds panic in `builtInHashPartition`. The panic is recovered and returned as error 20101, so the CN remains alive, but every affected UPDATE fails.

Reproduced repeatedly on current `main` commit `a4b0ce286d182c24efd5a349620ae37016262301` with literal, batched, and prepared UPDATE forms.

### Reproduction

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

create table t(
id int primary key,
k int null
) partition by hash(k) partitions 4;

insert into t values (1,1),(2,2),(3,null);
update t set k=null where id=1;
select * from t order by id;
```

### Actual result

The UPDATE fails and row 1 remains unchanged:

```text
ERROR 20101 (HY000): internal error: panic runtime error:
slice bounds out of range [:4] with capacity 0
...
github.com/matrixorigin/matrixone/pkg/sql/plan/function.builtInHashPartition.func2
```

The same panic occurs in three consecutive literal executions, a multi-row UPDATE, and a prepared UPDATE with a NULL parameter. It also occurs when the selected row's partition key is already NULL. The statements remain atomic and the service stays available.

Passing controls: inserting rows with a NULL HASH partition key succeeds, and normal reads return those rows correctly.

### Expected result

Updating a nullable HASH partition key to NULL must route the row using the same NULL hashing rule accepted by INSERT and must never panic.

### Analysis

In `builtInHashPartition.fillGroupStr`, the constant-vector branch slices `vec.GetData()` to one fixed-width value before checking `vec.IsConstNull()`. A constant NULL vector has no value bytes, so `GetData()[:4]` panics for an `INT` key. The analogous variable-vector branch checks the null bitmap before slicing individual values.