Add EMSX locate properties to TerminalLinkOrderProperties

[AlexCatarino]

Description

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

• LocateRequired (bool, default false) — when true, the brokerage emits EMSX_LOCATE_REQ = "Y"
• 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 LocReq / LocBrkr / LocId fields on the EMSX trading ticket.

Related Issue

N/A — surfaced via a TerminalLink customer report. The companion brokerage-side PR is QuantConnect/Lean.Brokerages.TerminalLink#PR_TBD (will be linked once opened).

Motivation and Context

The TerminalLink brokerage currently emits EMSX_SIDE = "SHRT" for short equity sales (since #PR for issue #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 defaults (false / null / 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