fix(web): let /apps Edit reveal a masked credential instead of offering "xxx"

[springfall2008]

Problem

Since #5053, the /apps page masks credentials with mask_secret_args() before rendering. That is correct for what the page shows. But each row's data-original-value / data-nested-original is also built from the masked copy. So clicking Edit on a credential filled the input with xxx.

You could not see or change the real key, only retype it from scratch. Saving it unchanged was already refused by the SECRET_MASK guard in html_apps_post(), so no key was lost. The editor was just unusable for credentials.

Fix

The page itself stays masked. No credential is written into the HTML.

• WebInterface.secret_row_attr() adds data-secret="1" to any row whose value was masked, top-level and nested (e.g. chat.providers.openrouter.api_key).
• GET /apps_value?path=<dotted path> (WebInterface.html_apps_value) returns the real value for one setting.
  • It refuses a missing path or anything that is not a single value (a whole list or group of settings), so it cannot pull a block of credentials out at once.
  • It exposes nothing that the unmasked /debug_apps?masked=0 download does not already expose behind the same access.
• JS revealSecretValue(): editValue() / editNestedValue() call it for a data-secret row before opening the input.
  • It replaces the row's original with the fetched value, so an unchanged Apply is a no-op rather than a write.
  • It also means the value type is worked out from the real value, not from xxx.

The existing server-side refusal to save xxx over a credential is unchanged.

Tests

Added to tests/test_web_apps_edit.py. They failed before the fix and pass now:

• Credential rows render masked and carry data-secret. A non-credential sibling does not. Neither credential appears anywhere in the page HTML.
• /apps_value returns the real value for nested and list-nested credentials, and for a plain value.
• /apps_value refuses a missing path, an unknown path, and a whole group of settings.
• The page script's Edit handlers fetch /apps_value for a data-secret row.

Also checked:

• ./run_all --quick and pre-commit pass.
• The generated page script passes node --check.
• A node run with a stubbed page and fetch: Edit on a masked octopus_api_key row requested ./apps_value?path=octopus_api_key and filled the input with the real key. Apply with no change queued nothing.

Not yet tried in a browser against a running Predbat.

Known, not addressed here

• Once revealed, the real value stays visible in that row after Cancel, until the page refreshes. The user has explicitly clicked Edit on it.
• Rows for settings Predbat does not recognise (unmatched_args) are still rendered unmasked on /apps.
• Editing a value that apps.yaml takes from secrets.yaml (!secret) writes the plain value into apps.yaml. This behaved the same before fix(security): redact secrets at log-write time, not just at serve time (#4770) #5053.

🤖 Generated with Claude Code