Attack paths are queries, not findings

[om986]

Problem

CSPM rules emit one finding per control. A rule may raise severity when the resource sits on a path, but the path itself stays a named query (internet-to-datastore). The console and exports list those separate findings.

The combination an operator should fix is one thing: an internet-reachable workload, a finding on that workload, and a CAN_ACCESS edge from that workload to a datastore. Today that combination is only visible by running the path query and reading findings beside it.

Done when

• A rules run (or a dedicated pass the CLI and API already expose) writes one finding per such combination.
• The finding records the path as ordered node ids.
• The findings list returns that row with the path attached.
• A reachable workload with no datastore path does not produce this finding. A path whose workload has no finding does not produce it.
• Existing per-control CSPM findings still run.

Design can land in this issue before code. The vulnerability hop is only as real as inventory-backed CVEs (#12). The first slice may use finding types that already exist on the workload.

Out of this issue

Disk snapshots, a permission solver, and a runtime sensor. Crown-jewel marking is a separate issue so this finding can later prefer datastores that carry it.

[om986]

Shipped in #68. A rules run now writes one attack-path finding per existing finding on an internet-reachable workload that can reach a datastore, and the findings list returns that path.