Smartphone bridge: name the third path, native TigerTag

[saucissefarciehumaine-prog]

One page, one subject, branched from current main (27ca0c4) — not stacked on anything.

The question this answers. philosophy/smartphone-bridge.md § Native RFID vs the bridge offers two paths, and files every native reader under the vendor's locked tag: "A printer that reads that vendor's locked tag — one brand only." Two things the wiki already documents no longer fit that description:

• the community's extended firmware makes the Snapmaker U1 read a TigerTag on the machine itself — compatibility/snapmaker.md calls it "the first printer where a TigerTag spool is recognized without any app in between";
• the BT-AMS-C mounts on a Bambu Lab AMS and "sends tag data to the printer / BMCU" — compatibility/third-party-hardware.md.

Both read TigerTag, so both work with every brand. That is the opposite of the one-brand lock the row describes, and the concept page is the only place where the distinction can be drawn.

A fact has one home — applied. No new page, and nothing restated: the row is split in two, the two exceptions are named in one paragraph, and each links to the page that owns it. The claims come from those pages, not from the reasoning; §6.4 of TigerTag-RFID-Guide says the same of the BT-AMS-C.

It argues for the bridge, not against it. Both paths stay exceptions — the paragraph says so, since the point of the concept is that the bridge never had to wait for them.

Two files, both locales, no new route and no sidebar entry needed. i18n/fr/ mirrors the change with its sourceHash refreshed; link targets, heading shape, table shape and code blocks are identical across the two.

🤖 Generated with Claude Code

[vercel]

@saucissefarciehumaine-prog is attempting to deploy a commit to the Tiger-Project Team on Vercel.

A member of the Team first needs to authorize it.