[Bug]: View metadata stays stale after source column type changes

## Summary

After an `ALTER TABLE ... MODIFY COLUMN` changes the type of a source column, a dependent View executes with the new type but retains its original type metadata in `DESC` and `information_schema.columns`.

This leaves metadata consumers with a schema that no longer describes the View result.

## Environment

- MatrixOne commit: `7cb78aa5f88e3b98163f6b3bffb5f71586c0cbbf`
- Server version: `8.0.30-MatrixOne-v1.3.0`
- Reference engine: local MySQL `8.0.45`

## Reproduction

```sql
CREATE DATABASE view_alter_column_matrix;
USE view_alter_column_matrix;

CREATE TABLE source_t (
id INT PRIMARY KEY,
code VARCHAR(5) NOT NULL UNIQUE,
qty INT NOT NULL DEFAULT 1,
price DECIMAL(10,2) NOT NULL
);
INSERT INTO source_t VALUES (1, 'short', 2, 1.25);

CREATE VIEW v_source_t AS
SELECT id, code, qty, price, qty * price AS total FROM source_t;

ALTER TABLE source_t MODIFY COLUMN code VARCHAR(60) NOT NULL;
ALTER TABLE source_t MODIFY COLUMN qty BIGINT NOT NULL DEFAULT 1;
ALTER TABLE source_t MODIFY COLUMN price DECIMAL(20,5) NOT NULL;

INSERT INTO source_t VALUES
(2, 'this-code-is-longer-than-five-characters', 5000000000, 12345.67891);

SELECT id, code, qty, price, total FROM v_source_t ORDER BY id;
DESC v_source_t;
CREATE TABLE ctas_view AS SELECT id, code, qty, price FROM v_source_t;
DESC ctas_view;
```

## Actual result

The View query correctly returns the long string, `BIGINT` value, and five-decimal value. `ctas_view` also has the updated source definitions:

```text
code VARCHAR(60)
qty BIGINT(64)
price DECIMAL(20,5)
```

However, `DESC v_source_t` and `information_schema.columns` retain the definitions captured at View creation:

```text
code VARCHAR(5)
qty INT(32)
price DECIMAL(10,2)
total DECIMAL(38,2)
```

The mismatch reproduced in three fresh database runs. The same SQL on MySQL refreshes View metadata to `VARCHAR(60)`, `BIGINT`, `DECIMAL(20,5)`, and the corresponding new expression type.

## Expected result

View metadata should match the columns produced by the current View definition after compatible source-column type changes.

## Revised implementation scope

This issue owns the lifecycle that refreshes persisted View column metadata after dependency DDL. It does not own output-column provenance rules.

View creation persists generated `TableDef` columns, while query-time `bindView` rebinds the stored SQL against current dependencies. `DESC` and `information_schema.columns` read the persisted catalog definition, so query execution or CTAS using the new source types is not sufficient evidence that the View metadata was refreshed.

After #26226 and #26232 define the authoritative View output metadata contract, dependency refresh must rebind the current View definition and regenerate its complete column definitions through that same path. It must not patch selected type fields or maintain a second metadata derivation implementation.

The refreshed catalog update must preserve View identity and persisted definition attributes and must not use DROP/CREATE semantics. A refresh failure must not leave a partially rewritten definition or silently present stale metadata as current; invalid, temporarily unbindable, retryable, and terminal failures require explicit handling.

## Acceptance criteria

- Compatible source-column changes refresh persisted type, width, scale, nullability, default metadata, and derived-expression result types as produced by the authoritative View schema generator.
- `DESC`, `information_schema.columns`, direct View queries, and CTAS observe a mutually consistent current schema.
- Direct Views, aliases, expressions, and transitive View-of-View dependencies are covered.
- Relevant ALTER execution paths, including metadata-only/INPLACE and COPY-style replacements, cannot bypass refresh.
- Catalog replacement preserves View identity, SQL text, SQL mode, default database, security attributes, ownership, and privileges.
- Tenant, subscription, snapshot, and missing or temporarily unavailable dependency contexts are resolved under the correct account and database semantics.
- Any deferred recovery is bounded, fair across more than one page of pending Views, concurrency-safe, and cannot let an older scan generation move shared progress backward.
- Public SQL-path tests verify both successful refresh and controlled failure/recovery behavior; focused tests cover catalog replacement, pagination, concurrency, and dependency-context boundaries.

## Dependencies

Implementation order: #26226 -> #26232 -> #26227. Prepared-plan invalidation after View replacement or deletion is a separate lifecycle and is not part of this issue.
## Duplicate check

Checked #7358 (closed expression-length issue) and #24436 (open direct CTAS schema tracker). Neither covers stale View metadata after source `ALTER TABLE`.