fix(frontend): reject defining watermarks on upsert source

[BugenZhao]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

There is no clear definition of watermarks for upsert/retract streams, and our current impl doesn't expect this to happen as well.

Previously, a SOURCE had to be append-only, allowing us to apply the WatermarkFilter directly once a user defined a watermark, without any checks. However, since we introduced support for upsert sources in #22856, this assumption is no longer valid, and we need to implement this check.

This PR also add tests for the error handling of defining watermarks on non-append-only tables.

Checklist

• I have written necessary rustdoc comments.
• I have added necessary unit tests and integration tests.
• I have added test labels as necessary.
• I have added fuzzing tests or opened an issue to track them.
• My PR contains breaking changes.
• My PR changes performance-critical code, so I will run (micro) benchmarks and present the results.
• I have checked the Release Timeline and Currently Supported Versions to determine which release branches I need to cherry-pick this PR into.

Documentation

• My PR needs documentation updates.

Release note

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Handle non-append-only inputs in StreamWatermarkFilter

The new assert!(input.append_only()) in StreamWatermarkFilter::new will panic whenever a source carries watermarks but its stream kind is upsert/retract. Older clusters could already contain such sources (the preceding binder check only blocks new ones), and planning a new MV on top of them or re-planning during recovery would now crash the frontend instead of returning a user-facing error. Consider returning a structured ErrorCode here or rejecting the plan earlier so existing non-append-only sources with watermarks don’t bring down the service.

Useful? React with 👍 / 👎.

[chenzl25]

LGTM

[BugenZhao]

This change is part of the following stack:

• fix(frontend): reject defining watermarks on upsert source #24113 <-- you are here 🤪
  • feat(frontend): support planning table with watermark-ttl #24121

_{Change managed by git-spice.}