Fix/input fix main

[brnkhy]

Summary:
On newer Unity projects (Unity 6 and up), this package failed to compile because of how we handled the optional Input System package. This PR makes the dependency explicit and reliable, so the SDK now builds correctly regardless of which input setup a project uses.

What changed:

com.unity.inputsystem is now a proper package dependency, so Unity always installs it alongside the SDK.
Input handling now follows the project's own Player Settings (Active Input Handling) instead of guessing based on whether a package happens to be installed.
Updated docs/README to match the new behavior.
Impact on existing projects:
No action needed. Projects using the old (legacy) input setup will keep working exactly as before — this only fixes projects that were previously broken by the compile error.

Bumped to v3.1.1 with changelog notes for anyone upgrading.

@flasher297

[Copilot]

Pull request overview

This PR updates the SDK’s example input backend selection to follow Unity’s Player Settings → Active Input Handling (via ENABLE_INPUT_SYSTEM) and makes com.unity.inputsystem an explicit UPM dependency so Unity 6+ projects no longer fail to compile due to mismatched package/asmdef expectations.

Changes:

• Switched input-system compile gating from MAPBOX_NEW_INPUT_SYSTEM (package-presence) to Unity’s built-in ENABLE_INPUT_SYSTEM (Player Settings driven).
• Declared com.unity.inputsystem@1.7.0 as a package dependency and updated the Examples asmdef accordingly.
• Updated README/docs/changelog and bumped package version to 3.1.1.

Reviewed changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
Runtime/Mapbox/Example/Scripts/PointerInput.cs	Uses ENABLE_INPUT_SYSTEM to select the correct input backend based on Active Input Handling.
Runtime/Mapbox/Example/MapboxExamples.asmdef	Removes versionDefines and adds an Input System assembly reference for the Examples assembly.
README.md	Updates dependency table and clarifies input backend selection behavior.
package.json	Bumps version to 3.1.1 and adds com.unity.inputsystem@1.7.0 dependency.
Documentation~/Migration-3.0-to-3.1.md	Updates migration notes to reflect the new hard dependency and selection mechanism.
Documentation~/CameraSystem.md	Updates Input System support section to describe Player Settings–based selection.
CHANGELOG.md	Adds v3.1.1 notes explaining the compilation fix and new dependency model.
.gitignore	Ignores local Claude configuration files/directories.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[flasher297]

Things worth flagging:

1. package.json formatting inconsistency (pre-existing, not introduced here, but now touched). The dependencies block mixes spaces and tabs ("com.unity.render-pipelines.universal" uses spaces, com.unity.nuget.newtonsoft-json and com.unity.burst use tabs). The new com.unity.inputsystem line uses a tab, consistent with its neighbors, so this PR doesn't make it worse — but since the file is being edited anyway, this would've been a cheap opportunity to normalize.

2. Missing trailing newline in MapboxExamples.asmdef (\ No newline at end of file) — pre-existing, not this PR's fault, but flagging since the diff touches the last line.

3. Version floor choice. 1.7.0 is pinned as the minimum for com.unity.inputsystem. Worth double-checking against actual API usage (Mouse.current, EnhancedTouch.Touch, TouchPhase) — if EnhancedTouch requires manual EnhancedTouchSupport.Enable() calls that were added/changed in later minor versions, confirm 1.7.0 is genuinely sufficient rather than an arbitrary "known good" number.

4. UGUI InvalidOperationException caveat is a real, separate landmine. The changelog is upfront that StandaloneInputModule breaks under Active-Input = "New"-only, requiring a manual InputSystemUIInputModule swap. That's good, honest documentation — but it means this PR only fixes compilation, not full runtime UGUI compatibility under "New" mode. Worth confirming this is explicitly out of scope rather than an oversight, since users following the docs to "New" could still hit a runtime exception the PR doesn't touch.

5. No test/CI changes in the diff. Given this is fixing a Unity-6-specific compile break, it'd be good to confirm (outside this diff) that CI actually builds against a Unity 6 target with default Active Input Handling — otherwise this exact regression could resurface undetected.

6. Physical-removal escape hatch in the changelog (editing package.json + asmdef GUID to fully remove the dependency) is a reasonable pressure-release for users who object to a hard dependency, but it's brittle/unsupported by design — fine as documented, just worth being aware support requests may follow.

Overall: correct, well-reasoned fix for a legitimate compile-breaking bug, with unusually thorough changelog/migration documentation. I'd approve with the version-floor and CI-coverage points as follow-ups rather than blockers.