Carrying metadata from OPC-UA into CogniteTimeSeries — units, isStep, and state sets

 We're migrating a production line from classic time series to CogniteTimeSeries in the data model, ingested by the OPC-UA extractor from a Siemens IIH server, and we'd like to understand how much of the metadata we hold at the source can travel with the signal rather than being reapplied afterwards. Three things, in increasing order of interest to us:

1.  Engineering units — the UnitId is discarded. Our server sends the full EUInformation: NamespaceUri = http://www.opcfoundation.org/UA/units/un/cefact, UnitId = 4937544, DisplayName = kW·h, Description = kilowatt hour. What lands in CDF is only the composed display string, in classic unit and now in sourceUnit. The typed reference is never populated: across 2,772 OPC-UA-sourced classic series in our production project, unitExternalId is set on zero, and on the data-model side the unit direct relation to CogniteUnit is null on all 854 series of the migrated line. We fill it afterwards with our own script, but the UNECE common code in UnitId is exactly the deterministic key that would make resolution automatic, and it's dropped. Is UnitId-based resolution to CogniteUnit supported or planned? If post-processing is the intended pattern, is there a published UNECE-code → CDF unit-catalogue mapping we should use instead of matching on display strings?
2. . isStep is derived solely from the OPC-UA DataType. In our line, exactly the 24 Boolean nodes come out isStep = true and all 830 others false — including Cur_State, Cur_Mode, Cur_Prog (UInt32 enums), the alarm/warning history codes (Int16), and every setpoint, all of which are step-wise by nature. Is there any way to declare this at the source — e.g. does the extractor read the standard HistoricalDataConfiguration.Stepped property, or can a custom node property be mapped onto isStep the way EngineeringUnits maps onto unit? (For contrast, the numeric/string distinction does arrive correctly, derived from DataType, so the mechanism clearly exists for some fields.)
3. State time series — can they be assigned at ingestion, and may we join the private preview? Our machines publish genuine state signals with a documented code registry (Cur_State, Cur_Mode, Cur_Prog; e.g. 8 = Lack, 16 = Tailback, 128 = Operating), which is precisely what a state time series expresses. We can see stateSet as a direct relation on CogniteTimeSeries in our project, with no target view resolvable — so we assume StateTimeSeries is gated. We'd like to be enrolled in the private beta. Beyond access, the question that matters for us architecturally: can a state set be assigned during ingestion — from an OPC-UA node property, an extractor mapping, or MultiStateStateSet-style configuration — or is it strictly a post-ingestion assignment? We're generating our OPC-UA models ourselves from a canonical definition, so if any of this can be declared in the model we would rather put it there once than reapply it per line, per migration.