False-positive secret detection blocks writing ordinary OAuth source code

## Description

When writing a Rust source file that implements Microsoft OAuth/PKCE, exxperts blocked the file operation because the source contained token-related field and variable names.

No API keys, credentials, bearer-token values, or other secrets were included. The file contained only normal Rust source code with identifiers such as:

```rust
struct TokenResponse {
access_token: String,
id_token: Option,
}
```

The write operation returned:

```text
Content policy blocked tool 'write': blocked API key/token-looking argument.
Do not retry with equivalent file/path/token access.
```

This appears to be a false positive caused by identifier names rather than actual credential values.

## Steps to reproduce

1. Open a room with write access to a local Rust project.
2. Ask the agent to create a Rust OAuth client module.
3. Include ordinary deserialization fields such as:

```rust
#[derive(serde::Deserialize)]
struct TokenResponse {
access_token: String,
expires_in: u64,
id_token: Option,
}
```

4. Attempt to write the source file using the workspace file-writing tool.

## Actual result

The complete file write is rejected as a token- or API-key-related operation.

The agent is also instructed not to retry, so it cannot split or otherwise complete the legitimate source-code change.

## Expected result

Source code containing credential-related identifiers should be allowed when it does not contain actual secret values.

Secret detection should distinguish between:

- source-code identifiers such as `access_token`;
- placeholders and type declarations;
- actual credential values with token-like entropy or known secret formats.

## Impact

This prevents exxperts from implementing common authentication functionality, including:

- OAuth 2.0 clients;
- OpenID Connect clients;
- token-response deserialization;
- refresh-token handling;
- authorization-header middleware;
- credential-storage abstractions.

The user must manually create affected files outside exxperts before the agent can continue integration.

## Suggested improvement

Apply secret scanning primarily to values rather than identifier names. For source files, consider allowing common authentication identifiers when they appear in declarations or field access.

For example, this should be accepted:

```rust
struct AuthenticationResult {
access_token: String,
}
```

An actual high-entropy value assigned to that field should remain blocked.

## Environment

- **Product:** exxperts
- **Workspace mode:** Full access
- **Operation:** Creating a new Rust source file
- **File type:** `.rs`
- **Secrets included:** None

Start at the workspace file-writing tool and locate the secret-scanning decision that rejects Rust source containing identifiers such as access_token. Compare the identifier-only examples with high-entropy credential values, then verify that ordinary declarations are allowed while actual secrets remain blocked.

Written by the indexing model from the issue text.