perf: harden and accelerate Django indexing

[forhappy]

Summary

• fixes duplicate Python function-symbol IDs with portable deterministic AST identities and collision-safe Program merging
• reports explicit wall-clock totals for compass init, compass extract, and compass update
• accelerates cache-valid initialization and unchanged updates
• reduces forced full Django indexing from 21.08 seconds to approximately 5 seconds
• removes redundant filesystem canonicalization, graph copies, ID remapping, analysis indexes, and JSON allocations
• parallelizes independent resolver, finalization, clustering, analysis, and publication work
• excludes generated graphify-out content and prunes files removed from the configured scope

Root cause

The original Django run failed because two Python functions could receive the same provider symbol ID. After fixing that collision, profiling found repeated directory metadata calls, repeated AST ID rewriting, duplicated graph/index construction, cloned node and edge attributes during JSON export, and sequential analysis/publication work.

Django qualification

Release binary against /Users/haipingfu/Github/django, using the saved all-project scope:

4310 matched files: 3096 code, 1128 documents, 3 papers, 83 images
3105 indexed files
50944 nodes, 190401 edges, 1747 communities
Program analysis: 3038 modules, 32046 summaries, 0 conflicts

The generated node-ID set and complete edge identity set match the established Django output exactly. All runs completed without the duplicate function-symbol error.

User-facing compass init

Three consecutive cache-valid runs of:

/usr/bin/time -p compass init . --yes --force --timing

Compass operation / real process wall
3.77s / 3.82s
3.58s / 3.62s
3.50s / 3.54s

User-facing compass update

Three consecutive unchanged updates:

Compass operation / real process wall
1.09s / 1.11s
0.96s / 0.97s
0.95s / 0.96s

The immediate update after the final init was also 0.95s / 0.96s.

Forced full rebuild

Final isolated no-cache samples of:

/usr/bin/time -p compass update . --force --out <new-temp-dir> --timing

Compass operation / real process wall
4.96s / 5.03s
4.97s / 5.04s
5.11s / 5.17s
5.14s / 5.21s
5.21s / 5.27s

The best observed forced sample was 4.79s / 4.86s. Forced full builds now center around five seconds, but a strict sub-five process wall is not guaranteed under macOS scheduling variance. Cache-valid init and normal update are consistently below five seconds.

Checks

• cargo fmt --all --check
• cargo test -p compass-core -p compass-files -p compass-graph -p compass-resolve -p compass-output
• cargo test -p compass-cli --tests -- --skip native_hooks_are_self_contained_safe_and_preserve_user_content
  • the skipped pre-existing hook assertion is path-sensitive because this worktree path contains python
• focused borrowed-JSON equivalence regression
• complete Django node-ID and edge-identity comparison
• repeated real /usr/bin/time -p init, update, and forced-update samples
• git diff --check

Per repository-owner direction, graphify update . was not run.

Related: #46