[fix](test) Stabilize lineage skip internal schema test

[seawinde]

What problem does this PR solve?

Issue Number: N/A

Related PR: N/A

Problem Summary:

LineageUtilsSkipTest.testSkipInternalSchemaInsert could fail
intermittently in FE UT with Failed to acquire catalog lock. Try again.

Root cause: In LineageUtilsSkipTest.beforeCluster(), the test enabled
FeConstants.enableInternalSchemaDb before the mocked FE cluster started.
This allowed the background InternalSchemaInitializer to run during test
startup. The background initializer and the test method both performed DDL,
so they could race on the catalog lock used by InternalCatalog.createDb().

This PR keeps the background internal schema initializer disabled for the
unit test and creates the required internal schema synchronously in
runBeforeAll().

File	Change Description
LineageUtilsSkipTest.java	Stop enabling the background internal schema initializer, create the internal schema synchronously before the test body, and remove duplicate per-test initialization.

Release note

None

Check List (For Author)

• Test
  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

./run-fe-ut.sh --run org.apache.doris.nereids.lineage.LineageUtilsSkipTest#testSkipInternalSchemaInsert

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?