Feature: add opt-in diagnostics with configurable redaction

### Problem

Troubleshooting Hiero Enterprise Java currently often requires stepping through code or adding ad-hoc logs. When a Mirror Node request returns an unexpected result, pagination behaves oddly, or a transaction is slow or fails in an unexpected state, there is no consistent opt-in diagnostic output across the base, Spring, and MicroProfile modules.

Different users also need different levels of visibility. Some only want high-level request, status, and timing information, while others need more detailed context. The library should make this easier without requiring users to expose sensitive data in logs.

### Solution

Add opt-in diagnostic profiles with configurable redaction.

Suggested model:
- `off` (default): no extra diagnostics
- `basic`: operation names, request path/query, response status, page/next-link presence, transaction state transitions, and elapsed times
- `verbose`: richer request/response summaries, pagination details, retry/error classification, and configuration-source diagnostics
- optional subsystem toggles so users can enable only what they need, for example Mirror Node, transaction lifecycle, or configuration diagnostics

Sensitive values should be redacted by default. At minimum, private keys, mnemonics/seed phrases, passwords, tokens, and secret configuration values should never be emitted in standard diagnostic modes.

If a less-redacted mode is considered useful for local development, it should be explicitly marked unsafe/dev-only and require deliberate opt-in.

Potential scope:
- Mirror Node HTTP diagnostics
- method/path/query
- response status
- pagination links
- summarized result counts rather than full payloads by default
- transaction lifecycle diagnostics
- submit, receipt, record, final status, elapsed time
- configuration diagnostics
- which source provided a property
- masked value / whether redaction was applied

### Alternatives

1. Keep relying on ad-hoc logs while debugging
2. Rely only on framework-level logging
3. Add a single global debug flag with full output

The first two are inconsistent, and the third is likely either too noisy or unsafe.

### Acceptance criteria

- diagnostics are disabled by default
- users can select a diagnostic profile and/or subsystem-specific diagnostics
- sensitive values are redacted by default
- private keys are never logged in standard modes
- the behavior is documented for both Spring and MicroProfile modules
- at least one test covers enabled diagnostics and redaction behavior

No files or tests are identified. Start by mapping the base, Spring, and MicroProfile modules and their existing logging and configuration entry points, then define the diagnostic profiles, subsystem controls, and redaction boundaries. Done means diagnostics are opt-in, sensitive values remain redacted, Spring and MicroProfile behavior is documented, and enabled diagnostics plus redaction are tested.

Written by the indexing model from the issue text.