[v2] Replace instruction arguments with a single data type node

[lorisleiva]

Today in v1

Instructions describe their data as arguments: instructionArgumentNode[], where instructionArgumentNode is a near-duplicate of structFieldTypeNode plus instruction-only machinery: contextual default values (instructionInputValueNode — account values, argument values, resolvers), extraArguments (client-only inputs that are never serialised), and resolverValueNode (an opaque pointer to a renderer-specific function). Accounts and events describe data with a type node; instructions are the odd one out, and the extra machinery bakes renderer-era concerns into the standard.

Proposal

1. data is a type node

// v1
{
    "kind": "instructionNode",
    "name": "initialize",
    "arguments": [
        {
            "kind": "instructionArgumentNode",
            "name": "bump",
            "type": { "kind": "numberTypeNode", "format": "u8" },
            "defaultValue": { "kind": "accountBumpValueNode", "name": "mint" }
        }
    ]
}

// v2 — a plain type node, usually a struct
{
    "kind": "instructionNode",
    "identifier": "initialize",
    "data": {
        "kind": "structTypeNode",
        "fields": [
            {
                "kind": "structFieldTypeNode",
                "identifier": "bump",
                "type": { "kind": "numberTypeNode", "format": "u8" },
                "defaultValue": { "kind": "injectedValueNode", "key": "bump" }
            }
        ]
    },
    "provides": [
        {
            "kind": "providedNode",
            "name": "bump",
            "node": { "kind": "accountBumpValueNode", "name": "mint" }
        }
    ]
}

instructionArgumentNode disappears. Contextual defaults use the existing inject/provide pattern: the struct field's default is an injectedValueNode (already a plain valueNode member), and the instruction's provides list — the scope where contextual values are legal — supplies the value under that key.

2. IDLs must be self-contained

New validation rule: every injection key must resolve to a providedNode in scope or carry a fallback. Whether an instruction can be built from its IDL alone becomes statically checkable — exactly what wallets, explorers and other non-interactive consumers need.

3. extraArguments and resolverValueNode are removed

Both are information gaps: the IDL claims an input exists but cannot say how to produce it. They are removed from the standard, including resolverValueNode's slots in the instructionByteDeltaValue and instructionRemainingAccountsValue unions. The migration path is namespaced plugins (#124) on the relevant node:

{
    "kind": "instructionAccountNode",
    "identifier": "associatedToken",
    "isWritable": true,
    "isSigner": false,
    "plugins": [
        {
            "kind": "pluginNode",
            "name": "codamaJs.resolver",
            "payload": { "name": "resolveAssociatedToken", "dependsOn": ["mint", "owner"] }
        }
    ]
}

Renderers that supported resolvers read their namespaced plugin; the standard itself stops pretending the slot is resolvable.

Open questions

• Plugin placement conventions for the former resolver call-sites (byte deltas, remaining accounts) — to be validated against real programs during the rc line.
• Whether any extraArguments use case is not covered by provides + plugins; same validation window.
• Field references from discriminators and display templates switch to path expressions ([v2] Introduce path expressions as a shared reference DSL #130) now that data can nest.

Migration

Arguments map to struct fields one-to-one; plain-value defaults carry over; contextual defaults become provide/inject pairs; extraArguments and resolvers become plugins under a codama-owned namespace.

---

Part of #102 — Tier B.