Fix style preferences: learn and match team's coding conventions

[andthattoo]

Summary

The fixer agent currently generates patches generically. But teams have strong opinions about fix style — preferring checks-effects-interactions over reentrancy guards, requiring NatSpec documentation, or following specific error message conventions. The product should learn and match these preferences.

Goals

• Let users set explicit fix guidelines per org (stored persistently)
• Implicitly learn fix style from past accepted patches
• Feed preferences into fixer prompts so patches match the team's conventions

Proposed Changes

1. Explicit fix preferences

Allow users to define fix guidelines once, stored per org in the OrgProfile:

fix_preferences:
  - "Prefer checks-effects-interactions over reentrancy guards"
  - "Always add NatSpec documentation to fixes"
  - "Match error message style: Protocol__ReasonDescription()"

2. Implicit style learning

Analyze past accepted patches (from the feedback loop's accepted verdicts) to infer:

• Preferred fix patterns for each vulnerability class
• Documentation style and conventions
• Error handling patterns
• Code formatting preferences

Feed these as few-shot examples to the fixer prompt.

3. Fixer prompt injection

Add a fix_preferences field to the OrgProfile and inject into the fixer agent:

• "Match this fix style: [examples from past accepted patches]"
• "This team prefers: [explicit guidelines]"

The implicit path is what makes the product feel like it learns rather than just stores config.

Dependencies

• Feedback loop feature (for accepted verdicts on patches)
• Cross-run memory / OrgProfile (for persisting preferences)

Context

• Fixer agent is implemented in fix_pipeline.py
• See docs/product-learning.md for full design rationale

[aktasbatuhan]

How about we build a lightweight profiler agent to fetch the given repo, analyze development style, then allow users to edit andapprove extracted style?

Again, similar to #74, we can use GitHub webhook to fetch code patches because sometimes users may change the suggested fixes before applying them, even though they accept them. Therefore relying on those would be safer.