Narrow bare, implicit-self attr_reader-style accessor calls

[apiology]

Summary

A nil-guard on a bare, implicit-self call (e.g. return nil if steps.nil?, where steps is an argless method like an attr_reader) left a later call to the same accessor (e.g. steps.empty?) unnarrowed — reported at castwide#1258 (comment).

Root cause: FlowSensitiveTyping#chain_pin's length-1 branch always went through find_var, which only matches tracked local/instance-variable pins. A bare steps reference is a :send node (method call), not :lvar, so lookup silently found nothing.

class Repro
  # @return [Array<Hash>, nil]
  attr_reader :steps

  def identify
    return nil if steps.nil? # or: return nil unless steps
    steps.empty? # was: Unresolved call to empty? on Array<Hash>, nil
  end
end

chain_pin now distinguishes a length-1 chain word rooted in a real :lvar/:ivar node from one rooted in a :send node (a 0-arg self-call), and synthesizes a pin against the enclosing closure (now threaded into FlowSensitiveTyping from each node processor's region.closure) instead of a variable's. process_call_chain's bare-truthy-guard handling is extended from chain length >= 2 to >= 1 for the same reason.

Based on gh-fix-1249 (castwide/solargraph#1258) since it depends on that PR's chain-narrowing infrastructure. Once castwide/solargraph#1258 merges, this should be retargeted at castwide/solargraph:master (or opened fresh there).

Test plan

• Added 2 regression specs (bare .nil? guard, bare truthy guard) to spec/parser/flow_sensitive_typing_spec.rb
• bundle exec rspec -- 1629 examples, 0 failures
• bundle exec rubocop on changed files -- no offenses
• bundle exec solargraph typecheck --level strong on changed files -- 28 pre-existing problems on gh-fix-1249 unmodified; this diff adds none (verified line-by-line)
• Manually reproduced the original comment's repro and confirmed it now type-checks clean

🤖 Generated with Claude Code

https://claude.ai/code/session_01PMbuVPLPj8CjHG8EkEQjrh

[apiology]

Claude: drafted while auditing @sg-ignore suppressions in a downstream project, reviewing before posting.

This fix narrows a bare accessor when the guarded expression is called again directly, but the narrowing doesn't propagate through an assignment into a fresh local.

Reproduction

# typed: true
# frozen_string_literal: true

class Repro
  # @return [Array<Hash>, nil]
  attr_reader :steps

  # @return [Boolean]
  def works
    return false if steps.nil?

    steps.empty?  # 0 problems - narrows correctly
  end

  # @return [Boolean]
  def still_broken
    return false if steps.nil?

    local = steps
    local.empty?  # Unresolved call to empty?
  end
end

Confirmed against the current fork tip (this PR's commit is already an ancestor).

[apiology]

Reopening to nudge CI ��� push at 2026-08-06T19:01:06Z never triggered a synchronize event (no check-runs created for commit 70992a5 after 20+ minutes, while other branches in this repo triggered CI within seconds).

[apiology]

Claude: investigated this report.

Doesn't reproduce at this branch's current HEAD, commit bbaf7f9.

Checked two ways:

1. solargraph typecheck --level strong on the exact repro from this comment (both works and still_broken) reports 0 problems, including a fresh (non-cached) run.
2. Direct ApiMap#clip_at probe on local.empty? infers local as ::Array<::Hash>.

Root cause it isn't hitting: BaseVariable#probe re-infers a local's assignment expression (Chain#infer) at the assignment's own source position, not at the point of use. local = steps sits inside the presence range FlowSensitiveTyping already recorded for the bare steps call from the .nil? guard, so the narrowing fact is already in scope when local's type gets computed — no propagation-through-assignment logic is needed for this shape.

Added a spec (narrows a bare, implicit-self attr_reader-style accessor assigned into a fresh local variable) matching this comment's repro to spec/parser/flow_sensitive_typing_spec.rb and pushed it to this branch: 70992a5. bundle exec rspec spec/parser/flow_sensitive_typing_spec.rb -- 52 examples, 0 failures, run locally.

GitHub Actions hasn't picked up this commit yet (unrelated platform outage), so CI hasn't confirmed this independently yet.

If you were seeing this fail in the downstream project outside this minimal repro, a fuller reproduction (e.g. the local reassigned conditionally, or read across a block boundary) would help narrow down what's different.