Some background and an example model which 'opens up' a bit what is happening behind the scenes should help you understand the AnyLogic response.
Background
AnyLogic conditions are checked at every step of the model (i.e., at model start and after every event created explicitly by the developer or implicitly via the AnyLogic elements used). AnyLogic also uses timeout 0 events under the covers to effect state transitions; i.e., if it decides a transition of any sort is due, it does not do it immediately but schedules an event for the same simulation time to do so, which will be triggered at the next step of the model if there are no other events at the same simulation time. If you have the Professional edition, you can see this at model runtime via the Events Viewer (see later).
Condition Transitions
Because of the above, the condition is evaluated at the start of the model. If it is true, a timeout 0 event is scheduled to effect the transition. When this fires, the condition is checked again (because it is possible it is no longer true due to intervening events at the same simulation time). If it is true this second time, the transition goes ahead.
Example Model
I adapted your example. I just have a Main with a statechart with two states and two transitions: a condition one (with your randomTrue(0.95) condition) from state 1 to state 2, and a timeout 1 one which sends state 2 back to state 1. By putting the condition inside a function (check), I can add some extra traceln statements so we can better see what's going on.
Run this (setting to Run Until time 0 so it pauses at model startup) with the Event Viewer shown. The condition evaluated true so you can see the timeout 0 transition event set up.
I also added some traceln messages for the condition transition occurring and the transition back to state 1. Here's a sample from a run. (The transitions will stop once the condition doesn't evaluate true twice in a row, and so will depend on the random seed chosen for the run.)
Checking condition at time 0.0: sampled true
Checking condition at time 0.0: sampled true
Probabilistically transitioned to state 2
Going back to state 1
Checking condition at time 1.0: sampled true
Checking condition at time 1.0: sampled true
Checking condition at time 1.0: sampled true
Probabilistically transitioned to state 2
Going back to state 1
Checking condition at time 2.0: sampled false
Checking condition at time 2.0: sampled true
Checking condition at time 2.0: sampled true
Probabilistically transitioned to state 2
Going back to state 1
Checking condition at time 3.0: sampled true
Checking condition at time 3.0: sampled true
Checking condition at time 3.0: sampled true
Probabilistically transitioned to state 2
Going back to state 1
Checking condition at time 4.0: sampled true
Checking condition at time 4.0: sampled false
Notice that there are three condition evaluations each time after the first transition. I presume this is because the condition is also evaluated when the state 2 --> state 1 transition event fires (after its action code completes but before the transition is actually completed). Whether it evaluates true or false at these points is irrelevant since the Agent is not in state 1 yet and so the state 2 transition is not 'active'. (This does seem slightly strange, since it would be more efficient for conditions only to be checked if the Agent is in a state where the condition transition is active. However, I have no other explanation for this extra evaluation otherwise.)
It then arrives in state 1 and so the condition is checked (immediately, without an event) and, if true, a state 2 transition event is setup (causing the second check when it fires).
