[SizzleUnrlsd]

Summary

The heap and aliasing abstraction of docs/architecture.md §22, coarse first as the document asks, and the mutations / side_effects fields of §19. Closes #35.

• Acceptance tests first (test: define heap, aliasing and mutation behavior), implementation follows.
• abstract/heap.py: one AbstractObject per allocation site (containers and calls at their instruction, parameters, module globals and imported symbols by name, loaded fields by owner and field), an AliasSet per value from a flow-insensitive points-to fixpoint over the SSA form, and two HeapLocation fields per object, elements and attributes. A field of a field collapses onto itself, so node = node.next loops stay finite.
• Taint and dependence states are keyed by value or heap location. Stores (SetItem, SetAttr), mutating method calls (append, extend, insert, add, update, setdefault, put) write the receiver's location; loads (GetItem, GetAttr, iteration) read it; call arguments and sink arguments carry the contents of what they point to. The issue's example, b = a; b.append(user_input); sink(a[0]), is a flow; unrelated containers and clean stores stay clean; TaintFacts.heap(location) exposes the heap taint.
• Function summaries gain mutations (per parameter and field: the other parameters and the external sources stored into it) and side_effects (the module globals mutated). Callers apply callee mutations to their own heap, so mutations compose through calls and, through the project index, across files. The cache codec carries them (format 2, older entries miss).
• The layer map moves interprocedural above abstract, since summaries now consume an abstract domain; the layers above shift by one.
• Not covered, by design of the coarse abstraction: aliasing through function returns, cross-method attribute state on self, and conditional expressions, which the HIR still rejects.

Closes #35