Remove 7 stale LaunchDarkly feature flags permanently on

[DAlperin]

Summary

Removes 7 LaunchDarkly boolean feature flags that have been uniformly enabled
in production (no individual targeting) for 1–3 years, hardcoding their
"on" behavior:

Flag	On since	Notes
enable_multi_worker_storage_persist_sink	2023-05	Dead code — defined in session vars but never read
persist_pubsub_client_enabled	2023-06	Always connect to PubSub
persist_pubsub_push_diff_enabled	2023-06	Always push diffs
storage_dataflow_delay_sources_past_rehydration	2023-10	Always delay sources past rehydration
enable_lgalloc_eager_reclamation	2024-02	Always use eager memory reclamation
persist_optimize_ignored_data_fetch	2024-05	Always optimize ignored data fetch
use_global_txn_cache_source	2024-05	No Rust code references, only test infra

How these were identified: Queried the LaunchDarkly API for all boolean
flags in the production environment that are on, have no individual
targeting rules, and whose targeting was last modified more than 3 months ago.
Then verified each flag's codebase references to confirm safe removal.

Changes

• Rust: Removed constant definitions, config registrations, and conditional
  branches — the "true" code path is now unconditional
• Python test infra: Removed from mzcompose defaults,
  UNINTERESTING_SYSTEM_PARAMETERS, parallel_workload flag lists, and
  redundant test overrides in test/upsert/mzcompose.py
• Docs: Updated generated compute-types/dyncfgs.md

Test plan

• cargo check passes for all modified crates (mz-persist-client,
  mz-storage-types, mz-compute-types, mz-sql, mz-compute, mz-storage)
• CI passes
• After merge, flags can be archived in LaunchDarkly

https://claude.ai/code/session_01BnvkhW8217L1E3e1sMAarQ

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

[ggevay]

(LGTM from the Adapter side)