[Bug]: Table-level publication accepts a view without its base-table dependencies

## Description

A table-level publication accepts a view as its only published object even when the view depends on an unpublished base table. The subscriber can create the subscription successfully and can read the view definition, but every query of the view fails because its base table is outside the publication scope.

The system should either reject this invalid publication scope or include/require the view's dependency closure. It should not create a subscription that is unusable by construction.

## Environment

- Branch: `main`
- Commit: `a73f76d109bd528ae2e53a4b8ab294422fb13e21`
- Deployment: isolated local launch, 1 Log / 1 TN / 1 CN
- Test date: 2026-08-28
- Official contract: table-level publication is documented by `CREATE PUBLICATION ... DATABASE db TABLE t1,t2 ACCOUNT ...`; database-level subscriptions also support views.

## Steps to reproduce

Publisher account:

```sql
CREATE DATABASE view_pub_db;
USE view_pub_db;
CREATE TABLE base(id INT PRIMARY KEY, v INT);
INSERT INTO base VALUES (1,10),(2,20);
CREATE VIEW v_only AS SELECT id,v FROM base WHERE v >= 10;

CREATE PUBLICATION p_view
DATABASE view_pub_db TABLE v_only ACCOUNT subscriber_account;
```

Subscriber account:

```sql
CREATE DATABASE s_view
FROM publisher_account PUBLICATION p_view;

SHOW CREATE VIEW s_view.v_only;
SELECT COUNT(*), SUM(v) FROM s_view.v_only;
```

## Actual behavior

Publication and subscription creation both succeed. `SHOW CREATE VIEW` returns the view definition, but querying it fails:

```text
ERROR 1146 (HY000): SQL parser error: table "base" does not exist
```

Compact 3/3 evidence:

```text
VIEW_ROUND=1 VIEW_ONLY=FAILED VIEW_DDL=1 ALL=2:30 WITH_DEPS=2:30 ERR=ERROR 1146 ... table "base" does not exist
VIEW_ROUND=2 VIEW_ONLY=FAILED VIEW_DDL=1 ALL=2:30 WITH_DEPS=2:30 ERR=ERROR 1146 ... table "base" does not exist
VIEW_ROUND=3 VIEW_ONLY=FAILED VIEW_DDL=1 ALL=2:30 WITH_DEPS=2:30 ERR=ERROR 1146 ... table "base" does not exist
```

## Expected behavior

One of these behaviors should be enforced consistently:

1. reject creation or subscription of a table-level publication whose selected view has unpublished dependencies, with a clear error; or
2. include the required base-table dependency closure so the subscribed view remains queryable.

Successful publication and subscription creation must not result in a permanently broken published object.

## Stability and controls

- View-only table-level publication: query failed 3/3 with the same missing-base-table error.
- Database-level publication control: subscribed view returned `COUNT=2, SUM=30` in 3/3 rounds.
- Explicit dependency control (`TABLE base,v_only`): subscribed view returned `COUNT=2, SUM=30` in 3/3 rounds.
- The view definition itself was present in the view-only subscription 3/3.
- Cleanup: all six test accounts and their publication/subscription objects were removed; account residue count was 0.

## Evidence

The failure is deterministic and occurs after both DDL operations report success. No concurrent activity, schema mutation, or large data is required.

## Code analysis

`pkg/frontend/publication_subscription.go:genPubTablesStr` validates only that every requested name appears in `SHOW TABLES`. It does not distinguish a view from a base table and does not validate or expand the view's dependency closure. The subscription resolver then enforces the restricted publication table list, so resolving `base` from the persisted view SQL fails. This directly matches the observed split state: the view definition exists, while its required relation is unavailable.

## Regression coverage

Add a BVT for table-level publications containing views:

1. view plus all base dependencies is queryable from the subscription;
2. view without a required base dependency is rejected with a stable error, or is expanded according to the chosen product contract;
3. multi-level views and a view joining two base tables enforce the same dependency rule;
4. rejected creation leaves no publication/subscription residue.

No big-data coverage is needed because this is deterministic catalog validation and name resolution.

## Related

- #9085 is historical and not a duplicate. Its old expectation was that views should not be published at all; current documentation and BVT behavior support views in database-level subscriptions. This issue concerns a table-level view publication being accepted without the dependencies required to execute it.