[Task] Reuse PostgreSQL initialization SQL for openGauss and remove the duplicate script #7520

Problem

openGauss maintains a separate full initialization script from PostgreSQL despite sharing much of its SQL syntax and schema. Schema, seed-data and plugin migration changes must be repeated, and the copies have already drifted. We should remove this duplicate maintenance surface while preserving openGauss support.

Evidence

Inspected master at 3116109d42f4e6ca0e71258e15ec5ed051bdc4a1:

• PostgreSQL initialization and openGauss initialization are not equivalent today. PostgreSQL creates a UNIQUE index on discovery_upstream(discovery_handler_id, upstream_url); openGauss creates a non-unique index on those columns. Permissions, plugin handles and some table definitions also differ.
• .github/scripts/native-sql-matrix.py selects db/init/og/create-table.sql for its native openGauss job.
• shenyu-e2e/shenyu-e2e-case/k8s/script/storage/storage_init_opengauss.sh copies that same openGauss script into the E2E database initialization directory.
• Runtime openGauss configuration and MyBatis interceptors are distinct. Sharing an initialization source does not justify removing those integrations.

Requested Change

• Use db/init/pg/create-table.sql as the canonical initialization source for PostgreSQL and openGauss wherever native compatibility is verified.
• Reconcile existing table, constraint, index and seed-data differences first. In particular, resolve the discovery-upstream uniqueness difference explicitly rather than silently dropping a constraint during consolidation.
• Delete the independently maintained db/init/og/create-table.sql after updating the native SQL runner, E2E storage initialization, packaging and documentation references. Keep only a small explicit compatibility overlay for any proven engine-specific SQL requirement.
• Preserve openGauss profiles, JDBC driver, runtime dialect handling, native database validation and storage E2E coverage.
• Leave historical upgrade scripts intact; any consolidation of those scripts requires a separate upgrade compatibility review.

Acceptance Criteria

• Native PostgreSQL and openGauss CI initialize from the same canonical source (plus any documented minimal overlay), and both pass on their supported versions. The openGauss storage E2E setup uses that source as well.
• Fresh installations preserve the intended schema, uniqueness guarantees and plugin/resource/permission/default-namespace seed semantics, with no orphan relations or duplicate handle natural keys.
• No independently maintained openGauss full initialization copy or dangling reference remains. Database support and installation documentation remain usable.