Fix type inference for and/or idioms and circular dependency in tracer

[RomanSpector]

Summary

• Fix type narrowing for x == nil and "default" or x pattern — the and handler in the tracer now propagates outNode when the right side is a truthy literal, so the or branch correctly infers the variable as non-nil
• Fix circular dependency in calcNode for assignments inside if/for blocks — a _compilingAssigns guard prevents incomplete types and stale marks from propagating when the if-handler's getNode(lastAssign) triggers recompilation of an already-compiling setlocal
• Filter no-unknown false positives when a node only contains a variable object whose base declaration has a known type

Closes #2236, #2374, #2494

Examples

Ternary idiom x == nil and "default" or x

---@param a string?
local function test(a)
    a = a == nil and "test" or a
    print(a) -- Before: unknown/string|nil, After: string ✓
end

Assignments inside if blocks

---@param a string?
local function test(a)
    if true then
        a = a or "test"
        print(a) -- Before: unknown, After: string ✓
    end
end

Variable in for loop

local test = 1
for i = 1, 100 do
    test = test + 1
    if test > 2 then
        test = test + 2 -- Before: unknown, After: integer ✓
    end
end

Test plan

• a = a == nil and "test" or a — a inferred as string, not string|nil or unknown
• Same pattern inside if true then ... end — no regression
• a = a or "test" inside if then block — a inferred as string
• Variable reassigned inside for loop (test = test + 1) — no unknown degradation
• if a and b then / elseif chains — no regression in type narrowing

[gemini-code-assist]

Code Review

This pull request addresses false positive "unknown" diagnostics and type degradation caused by circular dependencies. It introduces a guard in the assignment compilation process and allows falling back to base declarations when a type is not immediately known. Furthermore, it improves type inference for logical "and" expressions by propagating narrowed nodes when the right-hand side is a truthy literal. A suggestion was made to refine the truthiness check in tracer.lua by utilizing vm.compileNode and alwaysTruthy() for a more robust implementation.

[gemini-code-assist]

The current check for a truthy right-hand side of an and expression is limited to literals. This could be made more robust and general by using vm.compileNode and the existing alwaysTruthy() method on the resulting node. This would handle not just literals but any expression that can be determined to be always truthy, such as constants or function calls returning known truthy values.

            -- When the right side of `and` is a truthy expression, the `and`
            -- can only be false when the left side is false. Propagate the
            -- narrowed outNode so that patterns like `x == nil and "default" or x`
            -- correctly infer x as non-nil.
            local node2 = vm.compileNode(action[2])
            if node2:alwaysTruthy() then
                outNode = outNode1
            end

[RomanSpector]

The current check for a truthy right-hand side of an and expression is limited to literals. This could be made more robust and general by using vm.compileNode and the existing alwaysTruthy() method on the resulting node.

We intentionally avoid calling vm.compileNode inside the tracer walk — it can trigger cascading compilation and circular dependencies (we encountered this during development). The AST literal check is safe and covers the most common use case (x == nil and "default" or x where the default is a literal).