v3.0.3: Function parameters no longer shadowed by class defaults in typed objects

Fixes a name-resolution bug where a function parameter could be shadowed by an inherited class property of the same name while building a typed object. The result then differed from Apple Pkl.

Fixed

• Function parameters now take precedence over inherited members in typed objects (#212) @jdx. Suppose a function builds an object of a class that has a property with the same name as one of the function's parameters. In 3.0.2, a reference to that name inside the object body resolved to the property's class default (often null) and not to the argument. Because of this, hk's migrated pre-commit step ran --hook-stage null instead of --hook-stage pre-commit:

  class Step { stage: String?; check: String? }
  local function precommit(stage: String): Step = new {
    check = "run --hook-stage \(stage)"
  }
  result = precommit("pre-commit")  // result.check is now "run --hook-stage pre-commit"

  This follows the same lexical-scoping rule as the 3.0.1 fix. It applies to direct function calls, object methods, apply, callbacks, pipes, and output converter calls.

Full Changelog: v3.0.2...v3.0.3