Fix flaky KSP error for @DeepLink methods in Kotlin objects

[rossbacher]

Summary

• XProcessing's isStatic() for KSP relies on annotation type resolution to detect @JvmStatic. This can intermittently fail during incremental compilation with KSP2's Analysis API, causing methods in Kotlin object declarations to appear non-static and triggering Only static methods can be annotated with @DeepLink.
• Adds a fallback check in verifyMethod() that also accepts methods whose enclosing type is a Kotlin object, since all methods in objects are effectively static in JVM bytecode.
• This pattern (object FooDeepLinks with @JvmStatic methods) is used in 25+ modules in the Airbnb Android app.

Root Cause

The isStatic() check in XProcessing (KSDeclarationExt.kt) has 4 fallback checks for KSP:

1. JAVA_STATIC modifier — never set for Kotlin source (by design, KSP#378)
2. hasJvmStaticAnnotation() — resolves annotation type via annotationType.resolve().declaration.qualifiedName — can fail if resolution returns an error type
3. isCompanionObject — false for plain object (only true for companion object)
4. Top-level function — false (the object IS the enclosing class)

For methods in a plain object, check 2 is the only one that can succeed. When KSP2's lazy FIR-based annotation resolution intermittently fails during incremental builds, all 4 checks fail and the processor throws.

Test Plan

• Added testMethodInKotlinObjectWithJvmStaticCompiles
• Added testNonStaticMethodInClassStillFails
• All 37 existing processor tests pass