firebase-perf: TODO pointing at causal-signal alternatives for app-start detection

The timing-window heuristic in resolveIsStartedFromBackground() infers "was this
process forked to launch an Activity?" from the ordering of a posted runnable
vs the first onActivityCreated callback. That ordering already shifted once on
API 34+ (caused the original bug fixed in PR #7281, and the threshold-too-tight
follow-up in #8103) and could shift again on future OS versions.

Add a TODO documenting two cleaner alternatives so the next maintainer doesn't
have to re-derive them:

  - API 35+: ApplicationStartInfo / getHistoricalProcessStartReasons gives the
    OS's authoritative start reason (LAUNCHER, SERVICE, CONTENT_PROVIDER, ...).
    Removes the heuristic entirely on supported devices.

  - API 34: RunningAppProcessInfo.importanceReasonCode + .importance captured
    early in FirebasePerfEarly (before our own ContentProvider work mutates the
    cause), combined with the timing window as a fallback.

Comment-only change; no behavior or test surface affected.

Author: jrodiz

firebase-perf/src/main/java/com/google/firebase/perf/metrics/AppStartTrace.java

@@ -347,7 +347,25 @@ private void recordOnDrawFrontOfQueue() {
    * before `onActivityCreated`, the
    * assumption is that it was called immediately before the activity lifecycle callbacks in a
    * foreground start.
-   * See b/339891952.
+   * See b/339891952 and https://github.com/firebase/firebase-android-sdk/issues/8103.
+   *
+   * <p>TODO(b/339891952): Replace this timing-window heuristic with a causal signal.
+   * The current approach infers "was the process forked to launch an Activity?" from the
+   * ordering of a posted runnable vs the first onActivityCreated callback, which is
+   * inherently fragile (its calibration depends on Android scheduling behavior that has
+   * already shifted once on API 34+ and could shift again). Better candidates:
+   * <ul>
+   *   <li>API 35+: use {@code ActivityManager.getHistoricalProcessStartReasons} /
+   *       {@code ApplicationStartInfo}, which authoritatively reports the start reason
+   *       ({@code START_REASON_LAUNCHER}, {@code START_REASON_SERVICE},
+   *       {@code START_REASON_CONTENT_PROVIDER}, etc.). This removes the heuristic
+   *       entirely on supported devices.
+   *   <li>API 34: capture {@code ActivityManager.RunningAppProcessInfo.importanceReasonCode}
+   *       and {@code .importance} once early in {@code FirebasePerfEarly} (before any of
+   *       our own ContentProvider work mutates the cause), and combine with the timing
+   *       window as a fallback for ambiguous cases.
+   * </ul>
+   * Adopting either of these would also let the API-34-vs-pre-34 branch below collapse.
    */
   private void resolveIsStartedFromBackground() {
     // If the mainThreadRunnableTime is null, either the runnable hasn't run, or this check has