fix: feed_api_key field doesn't show its "stored" state after masking

[rjonesbsink]

Summary

Fixes the config.js half of #7. 07b9d1d already fixed the actual data-loss bug (data-secret="1" on feed_api_key in settings.php) and covered the 9-field audit + boolean-masking issue — this PR doesn't touch any of that.

What's left is the piece explicitly called out as a separate gap in that thread: applySettingsToForm() has no concept of the <name>_set sentinel the server sends for masked fields, so a correctly-configured feed_api_key still renders as an empty box, and the "external feed is disabled" banner still shows even though a key is in fact set.

Change

loadApiKeys() now reads feed_api_key_set and shows the same "stored — leave blank to keep, type to replace" placeholder loadSlackConfig() already uses for its own secret fields, tracking a data-configured flag so updateFeedKeyBanner() reflects the real state instead of just checking whether the box happens to be non-empty.

This branch previously also carried the data-secret="1" addition to settings.php, but that's now identical to what's already on main via 07b9d1d — dropped it to keep this PR to just the one remaining gap, rather than duplicating your own fix.

Testing

Verified end-to-end on a live install: with a key configured, the field now shows the "stored" placeholder and the banner stays hidden; saving an unrelated field on the same form no longer touches the key (confirmed via direct DB check) and the display now correctly reflects that.

[ejosterberg]

Reviewed this one too — it's good to go from my side. No security surface, no server-side change, ES5-clean, and it mirrors loadSlackConfig()'s existing pattern rather than inventing a new one.

I particularly like that the banner logic keeps the blank-and-configured case hidden, which is what "blank means keep the stored value" should look like to a user. That was the confusing part of #7 and this makes the state visible instead of implied.

It's still marked draft — flip it to ready and I'll merge it.

Thanks for splitting this out from the larger fix rather than bundling it. Reviewing a focused 22-line diff is a very different experience from reviewing it buried in a nine-file change, and I noticed.