Initialize RecoX and RecoY to fix first node bug

[jdkio]

There's a bug where the RecoX of the first node of the kalman track will be initialized to 18314 .

Reco_Tree->Scan("KalmanPos:TrackHitTruePos", "", "entryrange=100,110");
***********************************************
*        0 *        0 *           *           *
*        1 *        0 *     18314 * -1503.153 *
*        1 *        1 * 0.9841747 * -2416.708 *
*        1 *        2 *     18153 *     18153 *
*        1 *        3 * -1475.746 * -1484.912 *

That value corresponds to TMS_Const::TMS_Thick_End (a z value) so I thought it was being set to the wrong number at some point. But that was a dead end. Turns out all kalman node RecoX and RecoY values were uninitialized, and for some reason RecoX defaults to that value. But then Predict sets the value to a new one for all nodes except node 0 (the loop starts at node 1). This fixes it by initializing the RecoX to the same as x, and same with RecoY and y.

root [1] Reco_Tree->Scan("KalmanPos:TrackHitTruePos", "", "entryrange=100,110");
***********************************************
*    Row   * Instance * KalmanPos * TrackHitT *
***********************************************
*        0 *        0 *           *           *
*        1 *        0 * -1491.766 * -1503.153 *
*        1 *        1 * -2340.117 * -2416.708 *
*        1 *        2 *     18153 *     18153 *
*        1 *        3 * -1475.746 * -1484.912 *
*        1 *        4 * -2330.354 * -2399.559 *

@LiamOS, maybe you know if there's a better prediction than that? This seems slightly off since it's not taking into account the particle's trajectory, and only setting it to the hit x and y

[LiamOS]

Approved.

Accounting for the particle trajectory is difficult for the first node, as we have to assume some initial state, and the uncertainty on anything derived from Asa's reco is really large, and it should converge in the end anyway, especially when we (eventually) run it in reverse.

(I hope I've understood your point)