Define and test view-failure behavior for SQL and subscriptions

[cloutiertyler]

The ENV review in #5887 raised two separate questions about failures while materializing views for SQL queries and subscriptions. Track them here so the general view behavior can be reviewed separately from ENV publication and invalidation. See the review discussion.

1. Caller-visible behavior: when a view traps, exhausts its budget, or returns a failure, should SQL/subscription setup fail, or may it continue using the backing table? The intended contract needs confirmation. An empty result has not been established as a bug.
2. Instance disposal and transaction cleanup: preserve a trapped instance's disposal state even when an error returns before the normal success tuple. Audit rollback of earlier materializations and subscription reference counts when a later view fails.

Relevant code is ModuleHost::materialize_views, ModuleHost::call_view_inner, RefInstance, and InstanceCommon::{handle_cmd, handle_sql_cmd}. The proposed changes in #5887 include both general error propagation and trap bookkeeping; neither should be treated as a confirmed regression without an unmodified-master reproduction.

Validation for a follow-up:

• Reproduce on unmodified master using a view that fails independently of ENV. Record the commit and the actual SQL/subscription result.
• Cover an initially empty view and a previously populated view, including a query that materializes several views before a later one fails.
• Verify the agreed client error/result behavior, transaction rollback, and subscription reference counts.
• Verify that a trapped runtime instance is discarded and a subsequent healthy call succeeds.

Keep ENV-specific publication rollback, changed-value invalidation, and refresh of surviving materializations separate from this general behavior decision.