Re-queue reference dependents when removing a declaration

[st0012]

Summary

Found by the incremental consistency testing tool.

When invalidate_declaration removes a declaration, it unresolves the declaration's names and cascades structurally to ChildName/NestedName dependents. But Reference dependents of those names were not re-queued — constant references from surviving files that depended on the removed name would stay permanently unresolved. Additionally, references that did get re-queued but resolved to Unresolved(None) during delete-phase resolution were terminally dropped instead of retried.

This caused singleton classes to be lost after file deletion when a .new call was nested inside a compact-notation class sharing the same parent namespace (e.g. Parent::Target.new inside class Parent::Caller).

Reproduction

# parent.rb — defines the parent module
module Parent; end

# target.rb — defines a class under Parent (compact notation)
class Parent::Target; end

# caller.rb — a sibling class that calls .new on Target
# The .new call creates an Attached singleton name <Target>,
# which is how rubydex tracks that Target has a singleton class.
class Parent::Caller
  Parent::Target.new
end

When parent.rb and target.rb are both deleted and re-added:

1. Deleting parent.rb removes the Parent declaration
2. The removal cascades: Parent::Target and Parent::Caller names are unresolved (ChildName dependents)
3. Bug (fix 1): The constant reference for Parent::Target in caller.rb is a Reference dependent of the Parent::Target name — but the removal path only cascaded structural dependents (ChildName/NestedName), not Reference dependents. The reference was never re-queued.
4. Bug (fix 2): Even when a reference IS re-queued, during the delete-phase resolve() it resolves to Unresolved(None) (parent doesn't exist yet) and gets terminally dropped instead of retried.
5. After re-add, Parent::Target is recreated but the .new reference from caller.rb is gone — the singleton <Target> is never recreated.

[vinistock]

This is fine for now, but I think we need to review if Retry is still applicable or if we should just be re-enqueueing unresolved items.

Maybe that will simplify a lot.

[st0012]

The distinction is still needed in definition cases AFAICT. Just that for constant references they now should be processed the same way.