[docs] Polish integrate_with_flink doc: self-contained snippets and language-scoped notes

[wzhero1]

Linked issue: #777

Purpose of change

Doc-quality follow-ups for docs/content/docs/development/integrate_with_flink.md, found during integrate_with_flink doc verification (#743):

• Overview grammar: "By integrate agent with flink ..." → "By integrating agents with Flink DataStream/Table" (and capitalize Flink).
• Self-contained snippets (Python + Java, DataStream + Table): replace the bare from_source(...) / fromSource(...) / from_elements(...) / fromValues(...) ellipses with concrete calls; define YourPojo (a valid Flink POJO), MyKeySelector, and RowKeySelector; add the missing imports (ExternalTypeInfo, RowTypeInfo, BasicTypeInfo, Schema, DataTypes, KeySelector, ...); and link each section to a runnable quickstart example.
• Java "always nested row" comment: corrected — the agent output is exposed as a single anonymous column f0; declare f0 with the agent's output type (a scalar type for scalar output, a nested ROW(...) only for composite output). Matches the flat column("f0", DataTypes.STRING()) in FlinkIntegrationTest.testFromTableToTable.
• Python vs Java column naming: document why the schemas look different — Python names output columns via the RowTypeInfo field names passed to to_table(), while Java's toTable(Schema) exposes the agent output as a single f0 column (it calls fromDataStream(DataStream<Object>, schema) internally).

Tests

Documentation-only change; no runtime impact. Verified manually:

• Both Java snippets compile against Flink 2.2.0 with JDK 11 (javac clean; the POJO/KeySelector helpers as static nested classes, the pipeline fragments as methods).
• Python snippets py_compile clean; MyKeySelector(), ExternalTypeInfo(RowTypeInfo([...], ["result"])), and Schema.new_builder().column("result", DataTypes.INT()).build() constructed on pyflink 2.2.1 (output_type ↔ schema consistent); imports run-checked in the venv.
• All four linked example files exist; no bare (...) left in executable code.
• Hugo renders clean: shortcodes balanced (tabs/tab/hint) with no raw shortcode leakage, both code blocks render inside each tab, and both example links resolve.

API

No public API changes.

Documentation

• doc-needed
• doc-not-needed
• doc-included

Closes #777

[wenjin272]

LGTM.

Regarding point four in #777, I believe we should reconsider the API design in the next release to align the Python and Java implementations and improve usability as much as possible. However, for version 0.3, providing a clear explanation in the documentation should be sufficient.