Support orders placed outside of the algorithm

[AlexCatarino]

Description

Supports orders placed in the Tradier account outside of the algorithm, like TradeStation, Alpaca and IB do. The fill polling converts an unknown order and offers it through OnNewBrokerageOrderNotification; a brokerage message handler returning true from HandleOrder takes ownership and the order is tracked from then on: Submitted, the fills it already had, and every later update through the regular polling path.

• Declined orders (the default handler) are only logged and left alone, like TradeStation and Alpaca; the algorithm keeps running.
• Orders the plugin cannot offer (multileg/combo/oto/oco/otoco classes, credit/debit/even types, a stop whose price could not be fetched) raise a one-time UnprocessableOrderId Warning and are not tracked, as Alpaca does for its multi-leg orders; the algorithm keeps running. Adopting orders with legs on top of Lean's contingent orders (Add contingent orders: OCO, OTO, OUO and brackets Lean#9828) is left for a follow-up.
• Order placement is no longer retried: a timed out POST can still reach Tradier, so a retry could place the order twice and have the first one offered back as an outside order. A failed placement invalidates the order with an OrderError warning instead of stopping the algorithm.
• The algorithm is never offered its own order: the verification waits for in-flight placements (a slow reply left the order visible to the poll before its id was on the Lean order) and rechecks the cache and the order provider under the fill lock before offering. Each offered id is verified as it is handled, so a failure later in the batch doesn't re-offer the ones already declined.
• GetOpenOrders skips the same unsupported orders with a warning instead of failing the launch.
• A closed order found with a partial execution reports the fill before its final status, so the portfolio applies it.
• TradierOrderClass gains oto, oco and otoco: one such order in the account failed the whole orders response to deserialize, breaking the fill polling.
• The unknown-id verification no longer disables itself after a failure, cannot run twice for the same order, and tells a failed fetch apart from an account with no orders.

Related Issue

N/A

Motivation and Context

Every unknown Tradier order id terminated the live algorithm, with no way to reconcile manual or broker-initiated activity.

Requires Documentation Change

No

How Has This Been Tested?

• Unit tests in TradierBrokerageAditionalTests cover the accepted, declined, unsupported (polling and launch), partial-fill, order-class deserialization and verification-retry paths, the single-attempt order placement, and the own-order and mid-batch failure guards (59 tests pass).
• Live against the Tradier sandbox with the LEAN Launcher, orders placed through the REST API after Running: a declined resting limit leaves the algorithm running; an accepted one emits Submitted and then Canceled after an API cancel. These runs predate dropping the decline warning and the order POST retries, which are covered by unit tests only.

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)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

🤖 Generated with Claude Code