bug: OceanBase collation fix does not upgrade existing schemas

[AlexStocks]

Describe the bug

The fix for #1276 changes the DDL used for new MySQL/OceanBase tables, but an existing deployment is not upgraded and is not rejected at startup.

identity_string() now uses utf8mb4_bin for opaque identity columns. Its own docstring states that create_all(checkfirst=True) does not rewrite existing collations and that existing MySQL/OceanBase schemas must be recreated.

The startup path still calls SQLAlchemy create_all(checkfirst=True) and has no schema-version or collation compatibility check. Consequently, upgrading the PowerContext package can leave the old utf8mb4_general_ci columns active while the Server starts normally.

The required recreation procedure is currently present only in a source-code comment, not as an operator-visible migration or startup diagnostic.

Related issue: #1276 fixed fresh-schema behavior. This issue tracks the existing-schema upgrade path.

Steps to reproduce

1. Install a PowerContext revision from before 3ce8753.
2. Initialize an OceanBase database whose identity columns inherit utf8mb4_general_ci.
3. Upgrade the package to commit a6e0dfe.
4. Start the Server against the existing database.
5. Inspect the identity-column collations, or rerun the Alpha/alpha and Turn-1/turn-1 reproduction from bug: OceanBase identity collation collapses case-variant scope_id and source_id #1276.

Current initialization path:

• src/powercontext/builtin/persistence/tables.py:51-62 explicitly says existing schemas must be recreated.
• src/powercontext/builtin/persistence/schema.py:25-39 only calls create_all(checkfirst=True).
• src/powercontext/builtin/persistence/oceanbase/profile.py initializes the profile without validating existing identity-column collations.
• No current CLI command or documented operator migration performs this upgrade.

This conclusion follows directly from the current initialization contract. A real legacy OceanBase instance was not mutated during this report.

Expected behavior

Upgrading an existing deployment must not silently retain a schema that violates byte-exact scope and source identity semantics.

One of the following should happen:

1. A tested migration safely converts every related identity column and constraint; or
2. Startup inspects the actual schema and fails closed with an actionable, credential-free error that identifies the required backup/rebuild/restore procedure.

The repository should include an old-schema-to-current integration test and operator documentation.

Actual behavior

The Server creates missing objects but does not alter or validate existing collations. An old database can start successfully while preserving the cross-scope collision behavior fixed for fresh schemas in #1276.

Environment

• PowerContext: 0.0.3.dev11+ga6e0dfe8b.d20260823
• Commit: a6e0dfe
• Affected backend: existing OceanBase/MySQL-mode schema created before 3ce8753
• Fresh SQLite schemas are not affected by this collation issue.

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.

[Vanillaxi]

Hi! I'm very interested in this.Could I give it a try?

[AlexStocks]

Hi! I'm very interested in this.Could I give it a try?

done.