Harden DOM targeting for composer upload injection

[JSvandijk]

Why this matters

The current upload-button injection relies on DOM targeting inside the upstream T3 Code UI. That is an intentional tradeoff, but upstream UI drift is a realistic long-term reliability risk.

The selector and fallback logic currently lives in apk/app/src/main/java/com/t3code/app/MainActivity.java, including the composer-targeting and fallback placement logic.

Scope

• Review the current selector strategy for locating the composer and attachment target.
• Reduce brittle assumptions where possible.
• Preserve graceful fallback behavior when the preferred placement target is unavailable.
• Keep the selector strategy and fallback behavior documented.

Acceptance criteria

• The selector logic is easier to reason about and less dependent on a single fragile DOM shape.
• Fallback placement still works when the preferred composer target is missing.
• Logs and diagnostics remain useful when the injection path cannot be resolved.
• Any behavior changes are reflected in the relevant docs or evidence notes.

Notes

This is a good contributor-sized reliability issue because it is constrained, visible, and directly tied to long-term maintenance cost.

[JSvandijk]

Maintenance check on May 5, 2026 after merging #19 and #20.

Current state:

• The current injection code already has fallback placement and console warnings when the preferred target cannot be found.
• No selector-hardening change was made in today's maintenance pass; the PRs were dependency/tooling and upstream-fit documentation work.
• The issue remains valid because upstream T3 UI drift is still the long-term risk, and the selector strategy is not yet documented as a stable contract.

Keeping this open as a scoped contributor task. Suggested next change: extract or document the composer target selection strategy, add a small fixture-based assertion for preferred and fallback paths, and then update the evidence notes.