feat: Add comprehensive documentation for binary reachability with PURL-resolved edges

- Introduced a detailed specification for encoding binary reachability that integrates call graphs with SBOMs.
- Defined a minimal data model including nodes, edges, and SBOM components.
- Outlined a step-by-step guide for building the reachability graph in a C#-centric manner.
- Established core domain models, including enumerations for binary formats and symbol kinds.
- Created a public API for the binary reachability service, including methods for graph building and serialization.
- Specified SBOM component resolution and binary parsing abstractions for PE, ELF, and Mach-O formats.
- Enhanced symbol normalization and digesting processes to ensure deterministic signatures.
- Included error handling, logging, and a high-level test plan to ensure robustness and correctness.
- Added non-functional requirements to guide performance, memory usage, and thread safety.

AGENTS.md

@@ -162,16 +162,19 @@ You will be explicitly told which role you are acting in. Your behavior must cha
 
 Your goals:
 
-1. Review new advisory files against:
-
-   * Archived advisories: `docs/product-advisories/archive/*.md`.
-   * Implementation plans: `docs/implplan/SPRINT_*.md`.
-   * Historical tasks: `docs/implplan/archived/all-tasks.md`.
-2. Identify new topics or features that require implementation.
-3. For genuinely new items (not already implemented or planned):
-
-   * Check the relevant module docs: `docs/modules/<module>/*arch*.md` for compatibility or contradictions.
-   * If contradictions arise, you must surface and discuss them with the requester (in prose) and propose alignments.
+1. Review each file in the advisory directory and Identify new topics or features. 
+2. Then determine whether the topic is relevant by:
+  2. 1. Go one by one the files and extract the essentials first - themes, topics, architecture decions
+  2. 2. Then read each of the archive/*.md files and seek if these are already had been advised. If it exists or it is close - then ignore the topic from the new advisory. Else keep it.
+  2. 3. Check the relevant module docs: `docs/modules/<module>/*arch*.md` for compatibility or contradictions.
+  2. 4. Implementation plans: `docs/implplan/SPRINT_*.md`.
+  2. 5. Historical tasks: `docs/implplan/archived/all-tasks.md`.
+  2. 4. For all of the new topics - then go in SPRINT*.md files and src/* (in according modules) for possible already implementation on the same topic. If same or close - ignore it. Otherwise keep it.
+  2. 5. In case still genuine new topic - and it makes sense for the product - keep it.
+3. When done for all files and all new genuine topics - present a report. Report must include:
+  - all topics
+  - what are the new things
+  - what could be contracting existing tasks or implementations but might make sense to implemnt
 4. Once scope is agreed, hand over to your **project manager** role (4.2) to define implementation sprints and tasks.
 5. **Advisory and design decision sync**: