fix: resolve signer auth loop and mutex placement

[barrydeen]

Summary

Three fixes based on external signer developer feedback:

• Mutex moved to RemoteSigner — the concurrency lock for intent-based signing now lives in RemoteSigner.intentMutex (companion object) instead of SignerIntentBridge. Queued nip44 operations retry the ContentResolver after acquiring the lock, so permissions granted by a prior intent signing allow the next queued request to succeed silently. For signEvent the CR retry is skipped inside the lock — calling the ContentProvider a second time can start the signer process in the background and race with the intent launch on fresh installs, causing Amber to hang.

• Auth deny cooldown — denyAuth() now records a 60-second cooldown per relay URL. If the relay disconnects and immediately reconnects after a denial, collectAuthChallenges suppresses the re-prompt for that window instead of showing the dialog again. This breaks the auth loop on relays like auth.nostr1.

• Skip reconnect on very brief background pauses — onAppResume now skips reconnectAll() entirely when the app was backgrounded for less than 5 seconds (e.g. switching to Amber and back). Previously even a 1-2s pause triggered a full disconnect/reconnect cycle, tearing down live connections and generating new AUTH challenges that fed back into the loop.

Test plan

• Fresh Amber login: tap Connect with Amber, approve, app loads normally — no unexpected Amber re-prompts
• Reject a relay AUTH prompt (not forever): relay reconnects but dialog does not immediately re-appear
• Switch to Amber to sign a post and back: relay connections stay alive, no reconnect churn in logs
• Long background (>30s): force reconnect still triggers as before