bregctl: issuer refresh renders browser secrets against an empty staging root

## What happens

`config::refresh_issuer_registration` (`crates/registry-bregctl/src/dev/config.rs`) reassigns the issuer description's `state_root` to a fresh staging directory before rendering.

`InteractiveApplication::client_secret_file` is a relative path (`secrets/application-{id}`), documented as "Relative owner-only file inside the issuer state root" in `crates/registry-thunderid-tooling/src/description.rs`. The renderer resolves it as `description.state_root.join(&app.client_secret_file)` (`crates/registry-thunderid-tooling/src/render.rs`).

With `state_root` pointing at an empty staging directory, that file is not there, and the render fails with "a browser application secret file could not be read".

Synthetic user passwords, written relative to the same root in `config.rs`, have the same shape.

## Severity

This fails loudly, which is why it was not fixed in #1057. It is still a real break of the refresh path for any session that has a browser application or a synthetic user.

## Likely fix

Either stage the owner-only files alongside the staged description, or keep the original `state_root` for secret resolution while staging only the rendered output. The second is smaller but splits one root into two meanings, so the first is probably the right shape.

## Scope

Local dev tooling only. No runtime or deployment surface.

Found by Codex review on #1057 and verified by reading the two call sites.

Start with config::refresh_issuer_registration in crates/registry-bregctl/src/dev/config.rs, then trace client_secret_file in crates/registry-thunderid-tooling/src/description.rs and its resolution in crates/registry-thunderid-tooling/src/render.rs. Check how staged descriptions and owner-only secret files are handled for browser applications and synthetic users. Done means refresh succeeds for sessions containing either case without weakening secret-file handling.

Written by the indexing model from the issue text.