feat(hilt): resolve @Binds and @Provides into BINDS edges - #1623

Almost nothing in an Android app is called by another Kotlin function:
the framework invokes lifecycle methods, the manifest declares
components, Hilt supplies dependencies, the Compose runtime calls
composables, annotation processors generate Room implementations, test
runners call @test, and `override fun` is reached through its supertype.
So the tool reports thousands of false positives.

Three changes:

- `override` functions are treated as live, using the `modifiers`
  property added in the parent commit. Guarded with IS NOT NULL, because
  'override' IN NULL is NULL rather than false in Cypher -- unguarded it
  would silently drop every function lacking the property from results.
- Android/JVM lifecycle names (onCreate, onBind, doWork, ...) are treated
  as entry points, scoped to func.lang IN ['kotlin','java'] so other
  languages keep the original global list untouched.
- ANDROID_DECORATOR_PRESET: a documented tuple of annotations meaning
  "something other than project code calls this" -- Compose, test
  runners, Hilt, Room, and @TypeConverter.

Measured on a real 2,861-file Android codebase: 7,141 findings without
the preset, 1,055 with it -- an 85% reduction, dominated by @test methods
and Hilt providers.

Two honest limits, both documented:

The override exemption is inert for Java, because only kotlin.py emits
`modifiers`; the lifecycle-name half does work for Java. And four preset
entries (Dao, HiltViewModel, AndroidEntryPoint, Serializable) annotate
classes rather than functions, so they cannot match a query that does
MATCH (func:Function) -- kept, with a comment, because the data exists
and it is the query's scope that makes them inert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

In a Hilt codebase, `@Binds abstract fun bindRepo(impl: UserRepositoryImpl):
UserRepository` is the only link between an interface and its
implementation. Without it every call resolves to the interface, so
`analyze callers` on the impl returns nothing, the impl looks like dead
code, and impact analysis dead-ends at every DI boundary -- which in a
clean-architecture Android app is every layer boundary.

Adds a BINDS relationship and resolves both Hilt mechanisms into it:

- @BINDS: source is the declared return type, target the single
  parameter type. Skipped if the arity is not exactly one.
- @provides: source is the return type, target the type constructed in
  the body, read from the function's recorded calls.

BINDS is declared as a REL TABLE GROUP rather than reusing INJECTS,
which is a single-binding REL TABLE (FROM Class TO Class). Hilt binds an
Interface to a Class, so reusing it would mean converting an existing
table to a group -- a migration hazard on databases already built.

Honest limits, stated in full because this is text-level resolution with
no type checker:

- Ambiguity is skipped rather than guessed. A @provides body with more
  than one type-resolvable call emits no row: neither first-call nor
  last-call is correct in general, since sequential construction wants
  the last and nested construction puts the wanted call first. A missing
  edge is visibly missing; a wrong one silently misdirects the very
  queries this exists to answer.
- Qualifiers (@nAmed) are not distinguished, generics resolve on erased
  names, multibindings are not modelled, and @provides bodies that
  delegate to a factory resolve to the factory call rather than the
  produced type.
- Where two label pairs both match, priority order decides, because a
  row carries names and paths but no labels.

Measured on a real 2,861-file Android codebase: 77 of 77 @BINDS
declarations resolved. @provides yields less (46 of 210) and legitimately
so -- those bodies are dominated by Room DAO accessors and static
factories, which have no first-party implementation node to point at.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>