Create Todo declarations for multi-level compact namespaces

[st0012]

Problem

class A::B::C where A is unknown panics when the class body contains def self.foo with instance variables:

thread panicked at rubydex/src/resolution.rs:386:42:
SelfReceiver definition should have a declaration

The panic occurs in handle_remaining_definitions because C's definition never gets a declaration — the resolution loop retries indefinitely and then gives up.

Fixes #663

Root cause

The Todo mechanism from #529 only handles one level of unknown parent in compact notation. For class Foo::Bar where Foo is unknown, resolve_constant_internal(Foo) returns Unresolved(None), which triggers Todo creation for Foo in name_owner_id.

For multi-level paths like class A::B::C, the flow differs:

1. name_owner_id(C) calls resolve_constant_internal(B)
2. B has ParentScope::Attached(A) — checks if A's name is resolved
3. A is unresolved → returns Retry(None) (line 1189)
4. name_owner_id passes Retry(None) through unchanged — never reaches the Todo creation branch
5. The unit is re-enqueued, but nothing ever resolves A, so the loop stalls

The Unresolved(None) branch (which creates Todos) is only reached when resolve_constant_internal goes through run_resolution for a bare name. Intermediate names with ParentScope::Attached short-circuit at the unresolved parent check.

Fix

In name_owner_id, merge Retry(None) with Unresolved(None) to eagerly create Todos for the entire parent chain:

// Before
Outcome::Retry(id) => Outcome::Retry(id),

// After
Outcome::Retry(Some(id)) => Outcome::Retry(Some(id)),
Outcome::Retry(None) | Outcome::Unresolved(None) => {
    // Create Todo for parent, recursively resolving the chain...
}

The recursive name_owner_id(parent_scope) call at line 1089 naturally handles arbitrary depth — each level either resolves to an existing declaration or creates a Todo. If real definitions appear later, the existing promotion mechanism upgrades Todos in place.

Retry(Some(id)) (pending ancestor linearization) is still passed through unchanged — this only affects Retry(None), which in the ParentScope::Attached code path exclusively means "the parent's parent name is unresolved."

[st0012]

@Morriar There are different ways to resolve the panic mentioned in the description. Looking at #529, I don't think 1-level-only todo declaration creation is intentional, so I opened this PR. If that's the intend, I think we should document it somewhere (architecture.md?), and I have another way to address the panic.