update_project: numeric fields are inferred as SINGLE_SELECT and skipped

[johnpreed]

Summary

The update_project safe-output handler cannot update an existing GitHub Projects v2 NUMBER field through the fields object. A JSON number is inferred as SINGLE_SELECT, so the handler reports a type mismatch and skips the update even though it has code to write number values.

Reproduction

Given an existing Project v2 field:

• Name: Comment Count
• Type: NUMBER

Emit this safe output:

{
  "type": "update_project",
  "project": "https://github.com/orgs/example/projects/1",
  "content_type": "issue",
  "content_number": 123,
  "target_repo": "example/repo",
  "fields": {
    "Comment Count": 30
  }
}

Actual behavior

The handler logs:

Field type mismatch for "Comment Count": Expected SINGLE_SELECT but found NUMBER.

The field is skipped and remains unchanged.

Expected behavior

The existing NUMBER field should be updated to 30.

For an existing field, its actual dataType should determine value coercion. If inference is needed for a missing field, a finite JavaScript number should infer NUMBER rather than SINGLE_SELECT.

Root cause

In v0.83.4, inferFieldDataType can return only DATE, TEXT, or SINGLE_SELECT. Numeric values therefore fall through to SINGLE_SELECT.

The inferred type is checked against the existing field before applying the update. Consequently, the later field.dataType === "NUMBER" branch is unreachable for an existing numeric field supplied through fields.

The same inference logic is present in v0.83.5, v0.84.0, and current main as of 2026-07-29.

Suggested fix

1. When a field already exists, use its actual dataType for coercion rather than rejecting it based on value inference.
2. When creating a missing field, infer NUMBER for finite numeric values.
3. Add coverage for updating an existing NUMBER field with a JSON number, including zero.

Environment

• gh-aw: v0.83.4
• Safe output: update_project
• Project: organization-owned Project v2