[PatrickSt1991]

Refs #44, refs #47, refs #43. Commits: the Tizen label, the certificate reading, every profile handed over, and the banner's Got it.

Tizen version label (#47, IPTV-Manager in #44). The catalog now says what Tizen each file asks for (required_version, from Apps2Samsung/tizen-community-packages#170 and Apps2Samsung/Apps2Samsung#926). The page reads this TV's platform version and:

• badges a build the TV is too old for with Needs Tizen X on cards, the selected card, pinned cards and variant rows, dims the card, and disables Install with the reason in the sheet; an app with a build for older sets lands on that build;
• sends the TV's version with every install, so the service checks the package's own manifest (required_version / api-version) before signing and pushing, for catalog installs and uploaded files alike, and answers NEEDS_NEWER_TIZEN with both versions;
• when the TV still refuses with [118, -19] (118019 on a 2018 set) or [118, -4], the message says what the package asks for instead of the bare code;
• Settings shows this TV's Tizen version.

Until the two catalog PRs are merged and a new community release and snapshot have run, nothing in the catalog carries the field, so the page shows no badges; the service-side check works from the package itself from day one.

Another certificate (HackTV in #44). An app installed from a phone or PC carries that device's author certificate, and the TV only updates it with the same one, so TV-Store's re-sign got install failed[118, -12] (118012 on a 2018 set). Now arming hands over every signing profile the phone or PC holds (Apps2Samsung/Apps2Samsung#927) and TV-Store updates in place:

• service/certs.js keeps them all ({ primary, certificates[] }, id = SHA-256 of the author leaf; a second device's arming adds its profiles; a 0.3.x one-profile file still reads), remembers which profile each package took, and gives the order to try;

• the service signs with the remembered profile (else the head's first choice) and, when the TV answers "same id and different certificate", signs again with the next profile from the same file until one is taken; /ping and Settings list the profiles on the TV;

• only when none matches:

• service/refusal.js reads the TV's refusal: "same id and different certificate", or a bare [118, -12] on a package the page says is on the TV, is CERT_MISMATCH; other [118, -12] reasons are CERT_REJECTED with the clock / internet / re-arm advice (as in Apps2Samsung#907);

• the install screen offers Remove the old copy and install again or Keep the old copy; the retry sends replace: true and the service runs 0 vd_appuninstall on its own connection before the push (a refusal is logged, the install goes ahead and the TV's answer is what the user sees);

• the app sheet says when an app came from a phone or PC (TV-Store never installed that package) and what happens on a mismatch;

• README: "Apps installed from a phone or PC".

test/refusal.test.js and test/certs.test.js cover the readings and the store; test/install.test.js runs the real service against the fake sdbd (A2S_SDB_PORT): retry with the next profile, remembered profile first, all refused, replace uninstalls first. All wired into both workflows; all tests pass. Verified in headless Chrome against a mock service with a Tizen 4.0 stub: the badge and disabled Install for IPTV Manager, a group landing on its 4.0 build, Settings showing "QE65Q6FNA · Tizen 4.0", the mismatch screen, the replace retry and the done screen. Not run on a TV.

Banner (#43). The "TV-Store vX is out" banner (and the renamed-copy one) gets a Got it that hides it for that catalog version, remembered on the TV; the next release brings it back. The On the TV row and the sheet keep saying the newer version. Checked in headless Chrome: banner, dismissed, still hidden after a reload.