`AttachThreadInput()` does not have `SetLastError = true`.

## Actual behavior

In my project, we received [a report](https://github.com/PSAppDeployToolkit/PSAppDeployToolkit/issues/1878) whereby a call to `AttachThreadInput()` was unsuccessful, with our wrapper throwing an exception saying "The operation completed successfully".

While the [docs](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-attachthreadinput) say "If the function fails, the return value is zero. To get extended error information, call [GetLastError](https://learn.microsoft.com/en-us/windows/desktop/api/errhandlingapi/nf-errhandlingapi-getlasterror)", the generated code does have `SetLastError = true` on it.

```C#
/// Attaches or detaches the input processing mechanism of one thread to that of another thread.
/// The identifier of the thread to be attached to another thread. The thread to be attached cannot be a system thread.
///
/// The identifier of the thread to which idAttach will be attached. This thread cannot be a system thread.
/// A thread cannot attach to itself. Therefore, idAttachTo cannot equal idAttach.
/// Read more on learn.microsoft.com.
///
/// If this parameter is TRUE, the two threads are attached. If the parameter is FALSE, the threads are detached.
///
/// If the function succeeds, the return value is nonzero. If the function fails, the return value is zero. To get extended error information, call GetLastError. Windows Server 2003 and Windows XP:  There is no extended error information; do not call GetLastError. This behavior changed as of Windows Vista.
///
///
/// By using the AttachThreadInput function, a thread can share its input states (such as keyboard states and the current focus window) with another thread. Keyboard and mouse events received by both threads are processed in the order they were received until the threads are detached by calling AttachThreadInput a second time and specifying FALSE for the fAttach parameter. The AttachThreadInput function fails if either of the specified threads does not have a message queue. The system creates a thread's message queue when the thread makes its first call to one of the USER or GDI functions. The AttachThreadInput function also fails if a journal record hook is installed. Journal record hooks attach all input queues together. Note that key state, which can be ascertained by calls to the GetKeyState or GetKeyboardState function, is reset after a call to AttachThreadInput. You cannot attach a thread to a thread in another desktop.
/// Read more on learn.microsoft.com.
///
[DllImport("USER32.dll", ExactSpelling = true),DefaultDllImportSearchPaths(DllImportSearchPath.System32)]
internal static extern winmdroot.Foundation.BOOL AttachThreadInput(uint idAttach, uint idAttachTo, winmdroot.Foundation.BOOL fAttach);
```

## Expected behavior

That the P/Invoke matches the documentation, if the documentation is indeed correct.

## Repro steps

1. `NativeMethods.txt` content:
```
AttachThreadInput
```

2. `NativeMethods.json` content (if present):
N/A

3. Any of your own code that should be shared?
4. N/A

### Context

- CsWin32 version: 0.3.248
- Win32Metadata version (if explicitly set by project): N/A
- Target Framework: net472
- `LangVersion` (if explicitly set by project): N/A

Start with the AttachThreadInput metadata entry and the NativeMethods.txt reproduction, then compare the generated C# declaration with the Win32 documentation. Done when the generated declaration correctly includes SetLastError = true and the result is verified for this API.

Written by the indexing model from the issue text.