feat(mobile): highlight and surface current user in suggested reviewers (port #2435)

[Gilbert09]

Summary

Ports desktop PR #2435 ("Highlight current user in signal suggested reviewers") to the mobile app, bringing the inbox report detail to parity.

Two gaps were closed in the mobile "Suggested reviewers" list:

1. Wire the current user through. The detail screen now reads the logged-in user's uuid via useUserQuery and passes it as meUuid to <SuggestedReviewers>, so the component's existing isMe highlight badge actually shows.
2. Reorder so the current user is first. When the logged-in user appears in the list and isn't already first, they're moved to the front — mirroring the desktop behavior. The reorder lives in a pure, testable orderSuggestedReviewers util alongside the other inbox derivation helpers.

The "Why was I assigned?" commit-reason tooltip from desktop is intentionally not ported: mobile's SuggestedReviewers does not render relevant_commits at all, and inventing a new commits UI was out of scope.

Changes

• apps/mobile/src/features/inbox/utils.ts — add orderSuggestedReviewers(reviewers, meUuid).
• apps/mobile/src/app/inbox/[id].tsx — call useUserQuery, reorder in the suggestedReviewers memo, pass meUuid to the component.
• apps/mobile/src/features/inbox/utils.test.ts — unit tests for the reorder (moves to front, no-op when already first / absent / no uuid).

Testing

• pnpm --filter @posthog/mobile test src/features/inbox/ — passing.
• tsc --noEmit clean for the changed files.
• Desktop code under apps/code untouched.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
apps/mobile/src/features/inbox/utils.test.ts:33-49
The three no-op cases all assert the same thing — that the original array reference is returned unchanged — across different inputs. Per the team's convention of preferring parameterised tests, they're a natural fit for `it.each`.

```suggestion
  it.each([
    {
      label: "already first",
      reviewers: [reviewer("me", "uuid-me"), reviewer("a", "uuid-a")],
      meUuid: "uuid-me" as string | null | undefined,
    },
    {
      label: "absent",
      reviewers: [reviewer("a", "uuid-a"), reviewer("b", "uuid-b")],
      meUuid: "uuid-me" as string | null | undefined,
    },
    {
      label: "null meUuid",
      reviewers: [reviewer("a", "uuid-a"), reviewer("me", "uuid-me")],
      meUuid: null as string | null | undefined,
    },
    {
      label: "undefined meUuid",
      reviewers: [reviewer("a", "uuid-a"), reviewer("me", "uuid-me")],
      meUuid: undefined as string | null | undefined,
    },
  ])("is a no-op when $label", ({ reviewers, meUuid }) => {
    expect(orderSuggestedReviewers(reviewers, meUuid)).toBe(reviewers);
  });
```

_{Reviews (1): Last reviewed commit: "feat(mobile): highlight and surface curr..." | Re-trigger Greptile}

[greptile-apps]

The three no-op cases all assert the same thing — that the original array reference is returned unchanged — across different inputs. Per the team's convention of preferring parameterised tests, they're a natural fit for it.each.

Suggested change

	it("is a no-op when the current user is already first", () => {
	const reviewers = [reviewer("me", "uuid-me"), reviewer("a", "uuid-a")];
	const ordered = orderSuggestedReviewers(reviewers, "uuid-me");
	expect(ordered).toBe(reviewers);
	});
	it("is a no-op when the current user is absent", () => {
	const reviewers = [reviewer("a", "uuid-a"), reviewer("b", "uuid-b")];
	const ordered = orderSuggestedReviewers(reviewers, "uuid-me");
	expect(ordered).toBe(reviewers);
	});
	it("is a no-op when meUuid is missing", () => {
	const reviewers = [reviewer("a", "uuid-a"), reviewer("me", "uuid-me")];
	expect(orderSuggestedReviewers(reviewers, null)).toBe(reviewers);
	expect(orderSuggestedReviewers(reviewers, undefined)).toBe(reviewers);
	});
	it.each([
	{
	label: "already first",
	reviewers: [reviewer("me", "uuid-me"), reviewer("a", "uuid-a")],
	meUuid: "uuid-me" as string | null | undefined,
	},
	{
	label: "absent",
	reviewers: [reviewer("a", "uuid-a"), reviewer("b", "uuid-b")],
	meUuid: "uuid-me" as string | null | undefined,
	},
	{
	label: "null meUuid",
	reviewers: [reviewer("a", "uuid-a"), reviewer("me", "uuid-me")],
	meUuid: null as string | null | undefined,
	},
	{
	label: "undefined meUuid",
	reviewers: [reviewer("a", "uuid-a"), reviewer("me", "uuid-me")],
	meUuid: undefined as string | null | undefined,
	},
	])("is a no-op when $label", ({ reviewers, meUuid }) => {
	expect(orderSuggestedReviewers(reviewers, meUuid)).toBe(reviewers);
	});

Context Used: Do not attempt to comment on incorrect alphabetica... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/mobile/src/features/inbox/utils.test.ts
Line: 33-49

Comment:
The three no-op cases all assert the same thing — that the original array reference is returned unchanged — across different inputs. Per the team's convention of preferring parameterised tests, they're a natural fit for `it.each`.

```suggestion
  it.each([
    {
      label: "already first",
      reviewers: [reviewer("me", "uuid-me"), reviewer("a", "uuid-a")],
      meUuid: "uuid-me" as string | null | undefined,
    },
    {
      label: "absent",
      reviewers: [reviewer("a", "uuid-a"), reviewer("b", "uuid-b")],
      meUuid: "uuid-me" as string | null | undefined,
    },
    {
      label: "null meUuid",
      reviewers: [reviewer("a", "uuid-a"), reviewer("me", "uuid-me")],
      meUuid: null as string | null | undefined,
    },
    {
      label: "undefined meUuid",
      reviewers: [reviewer("a", "uuid-a"), reviewer("me", "uuid-me")],
      meUuid: undefined as string | null | undefined,
    },
  ])("is a no-op when $label", ({ reviewers, meUuid }) => {
    expect(orderSuggestedReviewers(reviewers, meUuid)).toBe(reviewers);
  });
```

**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!