Enforce typed structured signal values

[PauloCarvalho13]

dataSignal and dataSignals accept arbitrary Kotlin values. Consequently, a JavaScript object literal passed as a String is correctly treated as a string value, even though it may look like a nested Datastar signal:

dataSignal("person", "{name: 'John Doe', age: 18}")

This produces:

data-signals="{person: '{name: \'John Doe\', age: 18}'}"

The generated signal is a string, not a JavaScript object. Expressions such as dataBind("person.name") therefore target a nested path on an incorrectly initialized signal and may overwrite its original value.
Nested signals should be initialized from typed Kotlin models rather than JavaScript object literals embedded in strings. The API should make the distinction between scalar and structured signal values explicit, preventing this error at compile time where possible.

Possible API

@DatastarSignal
data class Person(
    val name: String,
    val age: Int,
)

div {
    val person = dataSignal("person", Person("John Doe", 18))
    input {
        dataBind(person.on(Person::name))
    }
}

The following should not be usable to initialize a structured signal:

dataSignal("person", "{name: 'John Doe', age: 18}")

Acceptance criteria

• Nested signal initialization uses typed Kotlin models.
• A JavaScript object represented by a String cannot accidentally initialize a structured signal.
• Nested signal access can use signal.on(Model::property) instead of string paths.
• Invalid structured signal models are rejected at compile time where feasible.
• Signal values are not derived from arbitrary toString() results or evaluated lambdas.

Related to issue #15