[CodeByArnob]

Summary

Fixes #2 by removing a Flutter-side token requirement that conflicts with Puter web sign-in.

Root cause

The web sign-in flow authenticates Puter.js inside the embedded WebView and stores the user identity in Flutter, but it does not necessarily expose a raw auth token to Flutter SharedPreferences. Before every AI action, _executeCommand previously required that separately stored token and injected it into the JavaScript context. This caused valid WebView-authenticated users to be rejected before the bridge could use the active Puter SDK session.

Changes

• Removed the Flutter-side requirement for a cached raw token before AI actions.
• Removed per-request token reinjection that could overwrite or interfere with the active SDK session.
• Kept authentication enforcement in the JavaScript bridge, where the Puter SDK session is available and checked with puter.auth.isSignedIn().
• Preserved manual-token support and cached-token restoration paths.

Verification

• Reviewed the complete sign-in, bridge command, scanner request, and local storage flow.
• Confirmed the diff is limited to lib/features/auth/services/puter_bridge_service.dart.
• Automated Flutter tests and physical-device verification are still required before merge.

Test plan

• Sign in with a real Puter account using the in-app Puter flow.
• Scan a food image without a manually entered token.
• Confirm a signed-out user receives an authentication error.
• Confirm invalid sessions are rejected by the Puter bridge.
• Confirm manual token sign-in still works.
• Run dart format, flutter analyze, and flutter test.
• Verify on a physical Android device.