[opt] Should GlobalsAA be invalidated by PGOInstrumentationGen after inserting profiling counter updates?

`PGOInstrumentationGen` can insert instrumentation such as `llvm.instrprof.increment` counter updates and `llvm.instrprof.callsite` records while a previously cached `GlobalsAA` result remains available. Is it expected that later passes can then infer `memory(none)` on instrumented functions?

Reproducer: https://godbolt.org/z/YMTEqzhW8

```llvm
; repro.ll

target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i32 @callee(i32 %x) mustprogress willreturn {
entry:
ret i32 42
}

define i32 @caller(i32 %y) mustprogress willreturn {
entry:
%v = call i32 @callee(i32 %y)
ret i32 0
}
```

With cached `GlobalsAA`:

`stale.ll` has `@caller` containing a profiling increment but still marked `memory(none)`:

```llvm
; opt -passes='require,module(pgo-instr-gen),function-attrs' -S -o stale.ll repro.ll

...
define noundef i32 @caller(i32 %y) #0 {
entry:
call void @llvm.instrprof.increment(ptr @__profn_caller, i64 742261418966908927, i32 1, i32 0)
%v = call i32 @callee(i32 %y)
ret i32 0
}

attributes #0 = { mustprogress nofree nosync nounwind willreturn memory(none) }
```

With recomputed `GlobalsAA`:

`fresh.ll` does not mark the same function `memory(none)`:

```llvm
; opt -passes='require,module(pgo-instr-gen),recompute-globalsaa,function-attrs' -S -o fresh.ll repro.ll

...
attributes #0 = { mustprogress nounwind willreturn }
```

Inserting `invalidate` after `pgo-instr-gen` also matches the recomputed behavior.

If later cleanup passes trust the stale `memory(none)`, they may remove calls that should still execute (e.g., to collect PGO counts).

Start with the repro.ll module and run the two opt pipelines shown in the issue, comparing the cached and recomputed GlobalsAA results. Read the PGOInstrumentationGen, GlobalsAA invalidation, and function-attrs pass entry points to determine whether the profiling updates invalidate the cached result. Done means the instrumented caller no longer receives an incorrect memory(none) attribute, matching the recomputed behavior.

Written by the indexing model from the issue text.