Migrate RegisterAssembly to multithreaded execution

## Background
`RegisterAssembly` registers a managed assembly for COM interop, optionally producing a type library. It is currently `AppDomainIsolatedTaskExtension`, gated on `NETFRAMEWORK && FEATURE_APPDOMAIN`, so it only ever runs in the legacy single-threaded NET Framework host.

## Migration scope
- [ ] Apply `[MSBuildMultiThreadableTask]` (defensive — task only runs on .NET Framework)
- [ ] Implement `IMultiThreadableTask` only if any code path is reachable from a multithreaded host
- [ ] Absolutize paths via `TaskEnvironment.GetAbsolutePath()` for: Assemblies items, TypeLibFiles items, AssemblyListFile
- [ ] Use `TaskEnvironment.GetEnvironmentVariable()` for: N/A
- [ ] Use `TaskEnvironment.GetProcessStartInfo()` for: N/A (uses in-proc registration, not a child process)

## Known complexity factors
- AppDomain-isolated; `Execute` runs in a separate AppDomain — `TaskEnvironment` must round-trip across the boundary
- COM `ITypeLibExporterNotifySink` callbacks; native registry mutation
- NETFRAMEWORK-only; multithreaded mode is a .NET (Core) host concern, so practical migration value is low
- Mutates global system state (registry) — inherently not parallel-safe regardless of task plumbing

## Exit criteria
- [ ] Build clean, no new warnings
- [ ] Existing tests pass
- [ ] No regression in error message paths (Sin 2 audit)
- [ ] No leakage of absolutized paths into [Output] properties (Sin 1 audit)

## References
- Parent: #11834
- Migration skill: .github/skills/multithreaded-task-migration/SKILL.md