[codex] Fix LongBridge paper and SG execution guards

[Pigbibi]

Summary

• Change LongBridge cash-sweep/BOXX buys to use broker-validated marketable limit orders instead of raw market buys.
• Add paper/dry-run execution dedup markers and prior-report fallback so the same signal/effective date is not executed repeatedly.
• Localize dashboard diagnostic lines before rendering notifications, fixing mixed Chinese/English output like regime=risk_on in PAPER messages.

Root Cause

• BOXX safe-haven buys could still be submitted as market orders, which LongBridge can reject when buying-power holds or market-order buffers exceed local cash estimates.
• Monthly/windowed paper signals had no persisted execution marker, so a previously previewed signal could keep running inside the execution window.
• Dashboard text bypassed the notification localization path, so raw strategy diagnostics leaked into Chinese notifications.

Validation

• PYTHONPATH=/home/ubuntu/Projects/QuantPlatformKit/src python - <<'PY' ... renderer localization smoke ... PY
• python -m pytest tests/test_rebalance_service.py tests/test_runtime_composer.py tests/test_request_handling.py -q
• python -m ruff check notifications/renderers.py tests/test_notifications.py application/execution_state.py application/rebalance_service.py application/execution_service.py application/runtime_composer.py application/runtime_dependencies.py notifications/telegram.py tests/test_rebalance_service.py tests/test_runtime_composer.py

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 52628ca392

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Reserve execution markers atomically before submitting orders

When two Cloud Run requests/retries for the same signal overlap, both can pass this has_marker() check before either has recorded the marker, then both enter execute_rebalance_cycle and submit the same live orders. The marker write happens only after execution and uses a normal overwrite, so it does not act as a lock or create-if-absent reservation; the duplicate-run guard is therefore ineffective exactly in the concurrent invocation scenario it needs to protect. Use an atomic create/reservation step (e.g. GCS generation precondition / local exclusive create) before order submission and treat an already-existing marker as a skip.

Useful? React with 👍 / 👎.