t from useLingui nested in another t placeholder is not transformed #284

Description

When a t from useLingui() is used inside a placeholder expression of another t from the same useLingui(), the inner one is left as a tagged template on the runtime _ function. At runtime that calls i18n._() with a TemplateStringsArray, which returns "".

The Babel macro (@lingui/babel-plugin-lingui-macro 6.9.1) transforms the same input correctly.

Reproduction Steps

label.jsx:

import { useLingui } from '@lingui/react/macro'

export function Label({ device }) {
  const { t } = useLingui()
  return t`Calibrated for ${device || t`Microphone`}`
}

import { readFileSync } from 'node:fs'
import { transform } from '@lingui/native-tools'

console.log((await transform(readFileSync('label.jsx', 'utf8'), 'label.jsx')).code)

Output:

import { useLingui as $_useLingui } from "@lingui/react";
export function Label({ device }) {
    const { _: $__ } = $_useLingui();
    return $__(/*i18n*/ {
        id: "4SC7zv",
        message: "Calibrated for {0}",
        values: {
            0: device || $__`Microphone`
        }
    });
}

Expected Behavior

The inner t is transformed like any other, as the Babel macro does:

values: {
  0: device || _t(/** i18n */ { id: "1iY5xv", message: "Microphone" })
}

Other observations:

• The same nesting with t from @lingui/core/macro is transformed correctly.
• <Trans>Calibrated for {device || t`Microphone`}</Trans> is transformed correctly (since fix: transform JSX macros nested inside expression placeholders #279).
• It also fails when the outer message has other placeholders, e.g. t`${plural(n, { one: '# item', other: '# items' })} in ${box || t`Box`}` .

This may be the useLingui counterpart of #279 (placeholder expressions copied into values without being folded again).

Plugin Version

@lingui/native-tools 0.1.6, both via transform() and via @lingui/vite-plugin 6.9.1 with macroTransform: true. Not tested with the Wasm plugin.

Lingui Version

6.9.1

Environment

Node 24.21.0, macOS arm64, Vite 8.3.4. No SWC runtime involved, so the compatibility table doesn't apply.