Add tamper input mode with QR/manual options

[oroderico]

What is this PR for?

This PR introduces a configurable input method for the Tamper Check Code (TC), allowing the user to:

• Enter the code manually (existing behavior)
• Scan the code via QR using the device camera
• Choose the input method at runtime

The main goal is to reduce friction and typing errors, especially on devices without touch input or with limited navigation, while fully preserving the existing security model and default behavior.

Manual entry remains the default and is always available.

---

Changes made to:

• Code
• Tests
• Docs
• CHANGELOG

---

Did you build the code and tested on device?

• Yes, build and tested on Maix Cube

---

What is the purpose of this pull request?

• Bug fix
• New feature
• Docs update
• Other

---

Additional context / rationale

• The Tamper Check Code is already displayed to the user, so QR-based input does not introduce new secrets or weaken security.
• QR input is fully optional and opt-in.
• A new setting under Security allows users to select:
  • Manual
  • Scan QR
  • Ask every time (default)
• When changing the Tamper Check Code, the input method is forced to manual to avoid accidental or unintended changes.
• QR input reuses the existing camera/QR capture flow.
• QR data is sanitized (bytes → string, line breaks removed).
• Cancel / ESC behavior remains unchanged.
• No validation logic or other security-sensitive paths were modified.

---

Scope and impact

• Small, localized change
• Limited to the Tamper Check Code input flow
• No impact on other security features or UI layouts

[tadeubas]

The Tamper Check (TC) Code is not intended to defend against attackers or protect confidential data. Its purpose is to make firmware tampering obvious and to prevent casual bypass by normal users, not to provide strong access control. The device is intentionally open to modification and scrutiny.

This PR does not reduce attack friction. It only reduces user friction when entering an already user-known value.

QR input also enables the use of high-entropy TC Codes that may be impractical to type or memorize. This allows users to choose longer, more complex strings without worrying about typing errors, while preserving the same security assumptions and behavior.

I have no objections to this PR; the comments above are only meant to ensure that the author and reviewers share a clear understanding of what is involved.

If the ability to choose between manual input and QR input is being considered as an OPSEC, I already have a related PR #485 that intentionally does not address inconspicuous startup, in order to keep the scope small and improve the chances of an earlier merge has now a small QR code Kapp to address inconspicuous startup. The broader idea there is to later introduce a game or similar mechanism to improve OPSEC.

[oroderico]

The Tamper Check (TC) Code is not intended to defend against attackers or protect confidential data. Its purpose is to make firmware tampering obvious and to prevent casual bypass by normal users, not to provide strong access control. The device is intentionally open to modification and scrutiny.

This PR does not reduce attack friction. It only reduces user friction when entering an already user-known value.

QR input also enables the use of high-entropy TC Codes that may be impractical to type or memorize. This allows users to choose longer, more complex strings without worrying about typing errors, while preserving the same security assumptions and behavior.

I have no objections to this PR; the comments above are only meant to ensure that the author and reviewers share a clear understanding of what is involved.

If the ability to choose between manual input and QR input is being considered as an OPSEC, I already have a related PR #485 that intentionally does not address inconspicuous startup, in order to keep the scope small and improve the chances of an earlier merge. The broader idea there is to later introduce a game or similar mechanism to improve OPSEC.

@tadeubas

Thanks for the clarification — fully aligned.

This PR intentionally avoids framing TC input as a security or OPSEC feature.
The goal is purely to reduce user friction and error rates when entering an already user-known value, especially on constrained input devices.

No changes were made to validation logic, threat model, or startup behavior, and QR input remains strictly optional.