feat(docs): Add comprehensive documentation for Vexer, Vulnerability Explorer, and Zastava modules

- Introduced AGENTS.md, README.md, TASKS.md, and implementation_plan.md for Vexer, detailing mission, responsibilities, key components, and operational notes.
- Established similar documentation structure for Vulnerability Explorer and Zastava modules, including their respective workflows, integrations, and observability notes.
- Created risk scoring profiles documentation outlining the core workflow, factor model, governance, and deliverables.
- Ensured all modules adhere to the Aggregation-Only Contract and maintain determinism and provenance in outputs.

docs/modules/scanner/operations/entrypoint-lang-deno.md

@@ -0,0 +1,22 @@
+# Entry-Point Runtime — Deno
+
+## Signals to gather
+- `argv0` equals `deno` or path ends with `/bin/deno`.
+- Arguments include `run`, `task`, `serve`, or `compile` outputs.
+- Presence of `deno.json` / `deno.jsonc`, `import_map.json`, or cached modules (`/deno-dir`).
+- Environment (`DENO_DIR`, `DENO_AUTH_TOKENS`).
+
+## Implementation notes
+- Resolve script URLs or local files; for remote sources record the URL as evidence.
+- Distinguish between `deno compile` executables and the Deno runtime invoking a script.
+- Recognise `deno task <name>` by reading tasks from `deno.json`.
+- ShellFlow should already collapse Docker official entrypoint (`/usr/bin/env deno task start`).
+
+## Evidence & scoring
+- Boost for confirmed script/URL and config file presence.
+- Add evidence for permissions flags (`--allow-net`, `--allow-env`) to aid policy decisions.
+- Penalise when only the binary is present without scripts.
+
+## Edge cases
+- Deno deploy shims or adapters may further wrap the runtime; rely on wrapper catalogue.
+- When `deno compile` emits a standalone binary, treat it as C/C++ unless metadata persists.