Add EMSX locate properties to TerminalLinkOrderProperties

[AlexCatarino]

Description

Adds two new properties to TerminalLinkOrderProperties so algorithms can attach Reg SHO locate information to short equity sales routed through Bloomberg EMSX:

• LocateBroker (string) — counterparty broker code the shares are borrowed from (e.g. "BMTB"), emitted as EMSX_LOCATE_BROKER
• LocateId (string) — locate confirmation/ticket id returned by the lender, emitted as EMSX_LOCATE_ID

These correspond to the LocBrkr / LocId fields on the EMSX trading ticket. The TerminalLink brokerage emits EMSX_LOCATE_REQ = "Y" automatically whenever either identifier is set on a short equity sale, so no separate "required" flag is exposed here — presence of an identifier is the signal.

Related Issue

N/A — surfaced via a TerminalLink customer report. Companion brokerage-side PR: QuantConnect/Lean.Brokerages.TerminalLink#116.

Motivation and Context

The TerminalLink brokerage currently emits EMSX_SIDE = "SHRT" for short equity sales (since #115) but has no way to identify the lender. Prime brokers reject short sales without a locate attached, so the brokerage needs algorithm-supplied locate fields to route these orders successfully.

Requires Documentation Change

No. These follow the same shape as existing properties on the class (Broker, Account, HandlingInstruction, etc.) and will be picked up by the standard XML doc generation.

How Has This Been Tested?

Added two unit tests in Tests/Common/Orders/TerminalLinkOrderPropertiesTests.cs:

• LocateFieldsDefaultToEmpty — verifies both properties default to null
• SetsLocateFieldsFromPython — verifies the properties round-trip from a Python algorithm via PythonNet

Both pass alongside the existing SeamlesslySetsStrategyInPython test (3/3 in the test fixture).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description> — no associated issue; branch is feature-terminallink-locate-fields

🤖 Generated with Claude Code