Crypto and CryptoFuture delisting support

Summary

Historical hourly trade/quote data for several Binance USDⓈ-M perpetual futures
contracts is present in the QuantConnect cloud data store, but the contracts
have no row in Data/symbol-properties/symbol-properties-database.csv under
type=cryptofuture, so AddCryptoFuture(...) cannot subscribe to them (the
security service throws Failed to resolve base currency for '<TICKER>', it might be missing from the Symbol database or market '<MARKET>' could be wrong, Common/Securities/SecurityService.cs:152).

Evidence

The following tickers were once tradeable Binance USDⓈ-M futures contracts
(all later delisted from the futures venue by Binance) and have complete
historical trade+quote hour files in the cloud store
(cryptofuture/binance/hour/<ticker>_trade.zip /
cryptofuture/binance/hour/<ticker>_quote.zip both exist for each), yet none
of them has a type=cryptofuture row in the current
symbol-properties-database.csv:

• AKROUSDT
• BTTUSDT
• BZRXUSDT
• DODOUSDT
• KEEPUSDT
• LUNAUSDT
• NUUSDT
• YFIIUSDT

All eight tickers do still have a type=crypto (spot) row in the same file,
which is not equivalent - AddCryptoFuture specifically requires a
cryptofuture row (see Common/Securities/Crypto/Crypto.cs:139, which reads
SymbolProperties.QuoteCurrency to decompose the currency pair; without a
matching row the default account-currency quote is used instead, the ticker
does not end with it, and CurrencyPairUtil.TryDecomposeCurrencyPair fails).

Suspected root cause

symbol-properties-database.csv's cryptofuture rows appear to be
regenerated from Binance's current exchangeInfo listing. Once Binance
delists a USDⓈ-M futures contract, its row silently drops out of the next
regeneration - even though the previously-collected historical files for that
ticker remain valid and stay in the data store indefinitely. The result is
that historical data becomes permanently unreachable through the normal
subscription API for any contract Binance later delists, despite the data
itself being intact.

Proposed fix

The cryptofuture generation step should preserve a symbol's row once
delisted (or fall back to the last-known row) rather than dropping it,
similar to how equity delistings do not remove historical map-file/security
entries. Where the historical row differs from the current listing, the
row should be flagged (e.g. by an IsDelisted/last-active-date column) or
delisted rows appended after a snapshot, so AddCryptoFuture can still
resolve the currency pair for periods when the contract was live.

Open questions

• Is symbol-properties-database.csv's cryptofuture section generated by
  an automated job or hand-maintained? If automated, is the generator in this
  repo or an internal pipeline?
• Are there other delisted Binance USDⓈ-M contracts with the same gap beyond
  the eight sampled here?

Reported via Intercom conversation 215475946234200.

Start with Data/symbol-properties/symbol-properties-database.csv and trace how its cryptofuture rows are generated, checking whether that generator is present in this repository. Then follow Common/Securities/SecurityService.cs:152 and Common/Securities/Crypto/Crypto.cs:139 to understand the subscription failure; done means delisted historical contracts can still resolve through AddCryptoFuture without losing current listings.