memtrace-style-fingerprint

## Overview Every indexed Memtrace repository carries an empirical **style fingerprint** — descriptive histograms of competing AST idioms (ternary vs if-else, arrow vs function declaration, const vs let, await vs `.then`, early-return vs nested-return depth) computed at parse time and rolled up to Repository + Community level. This workflow tells you when and how to consult it so your edits match the codebase's existing idioms instead of drifting on stylistic choices the linter doesn't catch. The fingerprint is **descriptive, not prescriptive**. It reports what the codebase actually does, not what a style guide says it should do. If the codebase deviates from a popular convention for some reason, the fingerprint captures the deviation and you should match the deviation — that's the whole point. For prescriptive bug/security/perf rules, use `find_code_review_issues` instead. ## Best Fit | Situation | Action | |---|---| | About to write new code (function, component, module) in an indexed repo | Step 1 + Step 2 with `file_path=<the file you'll create>` | | About to edit an existing file | Step 1 + Step 2 with `file_path=<that file>` | | Asked "what's the convention here for X?" | Step 1 only — repo-mode fingerprint answers it | | Deciding between two equivalent idioms (ternary vs if, arrow vs fn-decl, await vs then) | Step 2 with `file_path` — `delta_from_codebase_norm` tells you which idiom matches the norm | | Reviewing a diff | Step 2 on each modified file — flag any new...