Fix Termux permission gating before first send

[Android-PowerUser]

Summary

• hardened the com.termux.permission.RUN_COMMAND check in PhotoReasoningScreen before sending the first user message
• added a dedicated hasTermuxRunCommandPermission() helper that verifies both:
  • runtime permission state via ContextCompat.checkSelfPermission
  • package permission grant flags (requestedPermissionsFlags) from PackageInfo
• kept existing denial handling flow (request permission dialog first, then redirect to app settings after repeated denials)

Why

The prior check could incorrectly behave as granted in some device/ROM scenarios, causing Screen Operator to proceed as if Termux access existed and skip the expected permission flow.

Validation

• Compiled with ./gradlew :app:compileDebugKotlin successfully.

---

Codex Task

[amazon-q-developer]

Review Summary

This PR improves Termux permission checking by adding a dedicated hasTermuxRunCommandPermission() helper that verifies both runtime permission state and package permission grant flags. The approach addresses scenarios where the runtime check alone could incorrectly report granted status on certain devices/ROMs.

Critical Issue Found

Logic Error (Line 207): The bounds check fallback returns runtimeGranted when the flags array is unexpectedly short, which undermines the hardening intent. This should return false to deny permission when PackageInfo state appears corrupted or inconsistent, ensuring the permission flow executes as expected.

Once the logic error is fixed, the implementation will correctly enforce the two-part verification and prevent bypassing the permission dialog flow.

---

You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.

[amazon-q-developer]

🛑 Logic Error: The index bounds check on line 207 allows the function to return runtimeGranted when index >= flags.size, but this creates a logic flaw. If the permission exists in requestedPermissions at position index but flags array is too short, the code assumes the runtime permission check alone is sufficient. However, this bypasses the intended hardening that verifies both runtime permission state AND the grant flags. When flags array is unexpectedly shorter than permissions array (indicating a corrupted or inconsistent PackageInfo state), the function should treat this as a permission denial rather than falling back to the potentially incorrect runtime check that the PR aims to fix.

Suggested change

	if (index == -1 || index >= flags.size) runtimeGranted
	if (index == -1 || index >= flags.size) false