My experience with adaptive parameters in WeBWorK is that they make answers much more sensitive to minor differences. Since WeBWorK is solving for the values of the parameters, small differences between the correct answer and the student answer can be amplified.
There are a couple of things going on here.
By default the Numeric context contains the variable x. When you add the variable t (and the two parameters), you now have a function of both x and t. In general this will be invisible to students, since it should still mark correct answers as correct (subject to the other considerations below), but in the background it is evaluating the correct answer at values of both x and t, and it also will allow students to enter answers in terms of both x and t.
What you want is for the only variables present to be t and the two parameters. Probably the most concise way to do this is to use
Context()->variables->are(t => 'Real', a => 'Parameter', b => 'Parameter');
Having x around isn't the source of the issues, but it can make things more complicated.
When WeBWorK displays a correct answer, it does not show the full precision for real numbers (see https://webwork.maa.org/moodle/mod/forum/discuss.php?d=5735), so despite the fact that it shows (-0.542857*t+0.186122)*e^(4*t) as the correct answer, if you display the values of $A and $B in the question, they are actually -0.542857142857143 and 0.186122448979592 respectively, so typing the answer to six decimal places ends up not being within the default tolerance, which is why it can be marked wrong depending on the values of the parameters a and b.
These sort of small numerical differences can be amplified by exponential functions, since they can easily lead to very small (or very large) function values. This can be somewhat mitigated by setting the domain of evaluation for t, with the goal of having the function values not get too close to 0. This is extra complicated for functions that involve exponential functions of opposite signs (like in this case the answer involves e^(4t) and e^(-3t)), since making one of those large makes the other one small. The default domain for each variable is [-2,2], but for a question like this you may want to keep the t-values closer to 0 by setting something like
$ans->{limits} = [0,1];
One more useful tool is to enable diagnostics for your answer checker:
ANSWER: [`\quad y_{p}(t) =\ `][__________________________________________________]{$ans->cmp(diagnostics=>1)}
This will show you the values at which WeBWorK is evaluating the answer, and give you some detail on numerical tolerances.
With all this being said, I have been using similar questions for years and still occasionally run into a situation where something that should be marked right is marked wrong because of numerical tolerances. In general I do my best to design questions so that the student answers are integers, which eliminates a lot of the rounding error. For your example, if you choose $c to be a multiple of $den (e.g. $c = $den*random(1,5,1);), then the values of $A and $B will be integers, which will reduce the rounding errors entered by students. With that being said, there is always the perspective that answers shouldn't always be nice, which is an individual decision.