feat(debug-tool): add pipe methods for getDevUrl/setDevUrl

[Huxpro]

Description

sparkling-debug-tool has native utility methods for reading/writing the dev server URL (SparklingDebugTool.devURL(fallback:) / .setDevURL(_:) on iOS, SparklingDebugTool.getDevUrl() / .setDevUrl() on Android), but these are not exposed as pipe methods. There is no JS→Native bridge for dev URL management.

This means JS code cannot read or write the persisted dev URL:

// These calls fail because no pipe method is registered
pipe.call('debugtool.getDevUrl', {}, callback)  // → error
pipe.call('debugtool.setDevUrl', { url }, callback)  // → error

Use Case

The Sparkling Go playground app has a Settings page with a Dev Server section that shows connection status and allows editing the dev URL. The UI is built but non-functional because the pipe methods don't exist.

Proposed Implementation

Add two PipeMethod subclasses to sparkling-debug-tool:

debugtool.getDevUrl — Returns the currently persisted dev URL (or empty string if none stored)

@objc(GetDevUrlMethod)
public class GetDevUrlMethod: PipeMethod {
    public override var methodName: String { "debugtool.getDevUrl" }
    
    public override func call(withParamModel paramModel: Any, completionHandler: CompletionHandlerProtocol) {
        let url = SparklingDebugTool.devURL(fallback: "")
        // return { code: 1, data: { url: "..." } }
    }
}

debugtool.setDevUrl — Persists a new dev URL

@objc(SetDevUrlMethod)
public class SetDevUrlMethod: PipeMethod {
    public override var methodName: String { "debugtool.setDevUrl" }
    
    public override func call(withParamModel paramModel: Any, completionHandler: CompletionHandlerProtocol) {
        // read url from params, call SparklingDebugTool.setDevURL(url)
    }
}

Same pattern on Android using SparklingBridgeManager.registerIDLMethod().

Dependencies

• iOS podspec needs to add SparklingMethod dependency (currently only depends on Lynx/LynxService/DebugRouter)
• Android build.gradle needs sparkling-method dependency
• Methods should be auto-registered via the existing autolink system

Related

• SPKViewController intercepts didLoadFailedWithURL without forwarding to containerLifecycleDelegate #84 — SPKViewController intercepts didLoadFailedWithURL without forwarding (blocks native dev URL recovery dialog)
• BaseDevtool pod from CDN ships empty LynxBaseDevToolResources.bundle (LogBox white screen) lynx-family/lynx#6386 — LogBox resources missing from CDN pod