An AcoustID key that AcoustID refuses is saved, and every import quietly skips the fingerprint #712

The problem

Settings accepts any AcoustID key that has the right shape, whether AcoustID will take it or not. When it will not, every import tries the fingerprint lookup, AcoustID answers "invalid API key", and identification falls back to the title search without a word. Settings keeps saying "A key ending in .. is saved", so there is nothing to tell the user their key never worked.

It is an easy key to get wrong. AcoustID gives each account two keys of exactly the same shape, ten letters and digits. The one on the profile page is a user key, for submitting fingerprints. Lookups need an application key, which only exists after registering an application at acoustid.org/new-application. The user key is the one people find first and paste.

Why it is worth catching

The fingerprint is the most reliable way a track gets identified: it names the exact recording, where a title search can land on a cover or a live cut. Someone who went to the trouble of registering, pasted a key and saw it saved has every reason to believe it is in use.

Constraints for a fix

• The key is the user's secret. Whatever checks it must send it only to AcoustID, never log it, and never echo it back in a response or an error.
• Offline, or with AcoustID down, a key cannot be checked. That must not stop someone saving it.
• The browser tests must never reach AcoustID.
• The message has to say which key to use instead, in every language the app ships, not just that the key failed.

Being worked on in the feat/song-identification branch.