[XRay][test] Raise fdr-mode.cpp unwrite threshold to deflake it (#211595)

It was observed failing on `sanitizer-aarch64-linux` ([build
40750](https://lab.llvm.org/buildbot/#/builders/51/builds/40750)).

The failure is in the `UNWRITE` run
(`XRAY_FDR_OPTIONS="func_duration_threshold_us=5000"`), which asserts
that every short function record is "unwritten" (rewound) except
arg1-logging records. In the failing output an `fA()` enter/exit pair
survived:

```
<stdin>:9:  - { func-id: 3, function: 'fA()', cpu: 0, thread: 1909237, kind: function-enter, tsc: 1784775492023431847 }
<stdin>:10: - { func-id: 3, function: 'fA()', cpu: 0, thread: 1909237, kind: function-exit,  tsc: 1784775492029462345 }
<stdin>:11: - { func-id: 4, function: 'fArg(int)', args: [ 1 ], ..., kind: function-enter-arg, ... }
```

so `UNWRITE-NEXT` (and `UNWRITE-NOT: function-enter`) no longer hold.

FDR mode only rewinds a function's enter record when its exit lands
within the threshold (`XRayFDRController::functionExit`: `TSC -
LastFunctionEntryTSC < CycleThreshold`).

```
1784775492029462345 - 1784775492023431847 = 6,030,498 cycles / 1 GHz = 6.03 ms  >  5 ms threshold
```

i.e. the thread was preempted for ~6 ms mid-function, so the record was
(correctly, by the runtime's own rule) not unwritten.

The proposed fix is to raise the `UNWRITE` run's
`func_duration_threshold_us` from `5000` to `100000`, so realistic
scheduling jitter cannot push a short function over the threshold. This
mirrors the accepted fix for the sibling test in
[PR #186611](https://github.com/llvm/llvm-project/pull/186611)
(`basic-filtering.cpp`), which flaked the same way.

GitOrigin-RevId: 130dccc2c3192d9f49c2e85bcd047ed67a9fa9e1