Resumo
O watch ampliado mostrou que o gerenciador possui uma lista ativa em 0x00149BB0: o guest insere os nos 0x009BDA70 e 0x009BDA40 e depois os remove. O campo 0x00149BC0 e separado e segue nulo.
Defeito
O caminho de 0x00114528 consulta o campo 0x00149BC0 (+0x30), enquanto a lista ativa observada fica em 0x00149BB0 (+0x20). O campo objeto+0x24 ainda chega zero ao zero-fill, que apaga o descritor usado depois por mpegbuff.
Solução aplicada
Ampliei a auditoria para 0x00149B90..0x00149BDF e correlacionei as escritas com os PCs 0x00114AF0 e 0x00114E90. Isso separa os dois campos e corrige qualquer leitura de que o contexto inteiro estivesse vazio. Nenhuma semantica guest foi alterada.
Detalhes e evidências
A inicializacao registra 0x009BDA40 em 0x00149BB4 e 0x009BE040 em 0x00149BB8. A lista +0x20 recebe nos transitorios e volta a zero; a lista +0x30 nao recebeu ponteiro nao nulo no replay. Ainda nao provei o nome/contrato desses nos nem por que o objeto chega a limpeza com +0x24 nulo. O replay termina em 0x0010FA9C, sem ACTION.ELF, frame ou gameplay. Ynix continua recompilador estatico nativo, nao emulador. Evidencias locais: build/goal019/combined-ee-iop/combined-run-loadfile.log; tests/goal019_combined_ee_iop_hook.cpp; docs/research/META_019_MOVIE_HEAP_LIST_CONTRACT.md.
META 019