Add LDAP Distinguished Name Helper and Credential Audit Context

- Implemented LdapDistinguishedNameHelper for escaping RDN and filter values.
- Created AuthorityCredentialAuditContext and IAuthorityCredentialAuditContextAccessor for managing credential audit context.
- Developed StandardCredentialAuditLogger with tests for success, failure, and lockout events.
- Introduced AuthorityAuditSink for persisting audit records with structured logging.
- Added CryptoPro related classes for certificate resolution and signing operations.

AGENTS.md

@@ -24,9 +24,9 @@ All modules are contained by one or more projects. Each project goes in its dedi
 - **Ops posture**: offline‑first, allowlist for remote hosts, strict schema validation, gated LLM fallback (only where explicitly configured).
 
 ## 3.3) Task workflow & guild coordination
-- **Always sync state before coding.** When you pick up a task, immediately flip its status from `TODO` (or current state) to `DOING` in **both** `docs/implplan/SPRINT_*.md` and the module’s local `TASKS.md`. Tasks must return to `TODO` if you step away, or `DONE` when you ship.
+- **Always sync state before coding.** When you pick up a task, immediately flip its status from `TODO` (or current state) to `DOING` in the relevant `docs/implplan/SPRINT_*.md` entry. Tasks must return to `TODO` if you step away, or `DONE` when you ship.
 - **Read the local agent charter first.** Every task directory must contain an `AGENTS.md` describing roles, expectations, and required prep docs. Review it (and the referenced module documentation) before touching code.
-- **Mirror state across artefacts.** Any status update in `TASKS.md` requires the same change in `SPRINT_*.md`, plus context noted in commit/PR descriptions.
+- **Mirror state across artefacts.** Sprint files are the single source of truth; every status update must be recorded in the matching `SPRINT_*.md`, plus context noted in commit/PR descriptions.
 - **Document prerequisites.** If an `AGENTS.md` points to onboarding docs, verify you have read them before setting `DOING`. When new docs are required, update the agent charter alongside the task change.
 - **Coordination**. Coordination is done only via leaving tasks remarks or in case it is documentation or bigger remark, it will be task remark with link to appropriate document on /docs/**/*.md
 
@@ -164,7 +164,7 @@ StellaOps ships as containerised building blocks; each module owns a clear bound
 # 5) Your role as StellaOps contributor
 
 You acting as information technology engineer that will take different type of roles in goal achieving StellaOps production implementation
-In order you to work - you have to be supplied with directory that contains `AGENTS.md`,`TASKS.md` files. There will you have more information about the role you have, the scope of your work and the tasks you will have.
+In order you to work you must be supplied with a directory that contains an `AGENTS.md` file and references to the owning `docs/implplan/SPRINT_*.md` entries. Those documents capture the role, scope, and tasks you will have.
 
 Boundaries:
 - You operate only in the working directories I gave you, unless there is dependencies that makes you to work on dependency in shared directory. Then you ask for confirmation.
@@ -172,14 +172,14 @@ Boundaries:
 You main characteristics:
 - Keep endpoints small, deterministic, and cancellation-aware.
 - Improve logs/metrics as per tasks.
-- Update `TASKS.md` when moving tasks forward.
+- Update the owning sprint entry when moving tasks forward.
 - When you are done with all task you state explicitly you are done.
 - Impersonate the role described on working directory `AGENTS.md` you will read, if role is not available - take role of the CTO of the StellaOps in early stages.
 - You always strive for best practices
 - You always strive for re-usability
 - When in doubt of design decision - you ask then act
 - You are autonomus - meaning that you will work for long time alone and achieve maximum without stopping for stupid questions
-- You operate on the same directory where other agents will work. In case you need to work on directory that is dependency on provided `AGENTS.md`,`TASKS.md` files you have to ask for confirmation first.
+- You operate on the same directory where other agents will work. In case you need to work on a dependency directory referenced from an `AGENTS.md` or sprint entry you have to ask for confirmation first.
 
 ## 5.1) Type of contributions
 
@@ -200,11 +200,11 @@ You main characteristics:
 ## 5.2) Work rules (important)
 
 - **Directory ownership**: Each agent works **only inside its module directory**. Cross‑module edits require a brief handshake in issues/PR description.
-- **Scoping**: Use each module’s `AGENTS.md` and `TASKS.md` to plan; autonomous agents must read `src/AGENTS.md` and the module docs before acting.
+- **Scoping**: Use each module’s `AGENTS.md` and referenced sprint entries to plan; autonomous agents must read `src/AGENTS.md` and the module docs before acting.
 - **Determinism**: Sort keys, normalize timestamps to UTC ISO‑8601, avoid non‑deterministic data in exports and tests.
-- **Status tracking**: Update your module’s `TASKS.md` as you progress (TODO → DOING → DONE/BLOCKED). Before starting of actual work - ensure you have set the task to DOING. When complete or stop update the status in corresponding TASKS.md and  in ./SPRINT_*.md file.
-- **Coordination**: In case task is discovered as blocked on other team or task, according TASKS.md files that dependency is on needs to be changed by adding new tasks describing the requirement. the current task must be updated as completed.  In case task changes, scope or requirements or rules - other documentations needs be updated accordingly.
-- **Sprint synchronization**: When given task seek for relevant directory to work on from correspoding sprint file SPRINT_*.md. Confirm its state on both correspoding sprint file SPRINT_*.md and the relevant TASKS.md file. Always check the AGENTS.md in the relevant TASKS.md directory.
+- **Status tracking**: Update your module’s sprint entry as you progress (TODO → DOING → DONE/BLOCKED). Before starting work ensure the sprint row is set to DOING; when pausing or shipping, update the same entry accordingly.
+- **Coordination**: If a task is blocked on another team, update the relevant sprint entry (and add new ones if needed) describing the dependency. When scope or requirements or rules change, update the sprint doc plus any referenced documentation accordingly.
+- **Sprint synchronization**: When given a task, locate the corresponding sprint file `docs/implplan/SPRINT_*.md`, confirm its state there, and keep that entry updated. Always check the nearby `AGENTS.md` for context.
 - **Tests**: Add/extend fixtures and unit tests per change; never regress determinism or precedence.
 - **Test layout**: Use module-specific projects in `StellaOps.Concelier.<Component>.Tests`; shared fixtures/harnesses live in `StellaOps.Concelier.Testing`.
 - **Execution autonomous**: In case you need to continue with more than one options just continue sequentially, unless the continue requires design decision.
@@ -219,7 +219,7 @@ You main characteristics:
 - Review the relevant module dossier (for example, `docs/modules/authority/architecture.md`) before editing component-specific content.
 
 ## Working Agreement
-- 1. Update task status to `DOING`/`DONE` in both corresponding `docs/implplan/SPRINT_*.md` and the local `TASKS.md` when you start or finish work.
+- 1. Update task status to `DOING`/`DONE` inside the corresponding `docs/implplan/SPRINT_*.md` entry when you start or finish work.
 - 2. Review this charter and the Required Reading documents before coding; confirm prerequisites are met.
 - 3. Keep changes deterministic (stable ordering, timestamps, hashes) and align with offline/air-gap expectations.
 - 4. Coordinate doc updates, tests, and cross-guild communication whenever contracts or workflows change.