Add inline, remove unused exception variable name, safe float computation

[mnorris11]

This is a patch to get it to work internally. It would be easier if things are in SVS, so next version upgrade we don't need to apply this patch.

Reason for changes:

1. inlining: This is from -Werror,-Winline-namespace-reopened-noninline.
2. Unused exception parameter: -Werror,-Wunused-exception-parameter.
3. Float change: acccording to AI: the shift 125 - e goes out of range for uint32_t when e is outside [102, 112]. The result is multiplied by zero so it's "dead" at runtime, but the shift itself is still UB. UBSAN catches it and 5 FP16 tests fail: WriteAndReadIndexSVSFP16, VamanaFP16TrainSaveLoadAndAdd, WriteAndReadStaticIVFFP16, WriteAndReadIndexSVSIVFFP16, IVFFP16TrainAndAdd.
4. index.h Thread clamping: per AI: "compute_centroid_distances (in common.h:675) partitions centroids across threads using StaticPartition(num_centroids). If you have more threads than centroids, some threads get an empty partition. The callback then calls batch.start() and batch.size() on those empty ranges, leading to OOB access into centroids.get_datum() and matmul_results[tid]. The fix clamps the thread pool size to at most the number of centroids at construction time, so every thread gets at least one centroid to work on."
5. sorted_buffer.h change: " back() returns candidates_[size_ - 1]. When the buffer is empty (size_ == 0), that underflows to candidates_[SIZE_MAX] — an OOB read. The original code evaluated back() before checking full(), so on an empty buffer it would access garbage memory before full() returned false and short-circuited the &&. Swapping the operands ensures full() is checked first; if the buffer isn't full, back() is never called. Classic short-circuit evaluation fix."

[rfsaliev]

Thank you @mnorris11 , for the contribution.
There are some suggestions, proposals and comments

[rfsaliev]

Hm, in case when (e < 101 || e > 113), this component is always 0:

return (b & 0x80000000) >> 16 |
           ... |
           static_cast<uint32_t>((e < 113) && (e > 101)) *
               ((((0x007FF000 + m) >> (125 - safe_e)) + 1) >> 1) |

// equal to:
return (b & 0x80000000) >> 16 |
           ... |
           static_cast<uint32_t>(e > 101 && e < 113) *
               ((((0x007FF000 + m) >> (125 - safe_e)) + 1) >> 1) |
// equal to:
return (b & 0x80000000) >> 16 |
           ... |
           static_cast<uint32_t>(false) *
               ((((0x007FF000 + m) >> (125 - safe_e)) + 1) >> 1) |
//equal to:
return (b & 0x80000000) >> 16 |
           ... |
           0 *
               ((((0x007FF000 + m) >> (125 - safe_e)) + 1) >> 1) |

[ibhati]

@rfsaliev please read this comment above:
Float change: acccording to AI: the shift 125 - e goes out of range for uint32_t when e is outside [102, 112]. The result is multiplied by zero so it's "dead" at runtime, but the shift itself is still UB. UBSAN catches it and 5 FP16 tests fail: WriteAndReadIndexSVSFP16, VamanaFP16TrainSaveLoadAndAdd, WriteAndReadStaticIVFFP16, WriteAndReadIndexSVSIVFFP16, IVFFP16TrainAndAdd.

[rfsaliev]

Suggested change

	} catch (const ThreadCrashedError&) {
	} catch (const ThreadCrashedError& SVS_UNUSED(err)) {

[rfsaliev]

Please, use SVS formatting rules.

[rfsaliev]

IMHO, this change will negatively affect usability and maintainability for further API major versions.
Instead, a macro can be used here which value defined in version.h depending on SVS_RUNTIME_API_VERSION, e.g.:

#if (SVS_RUNTIME_API_VERSION == 0)
...
#define SVS_API_V0 inline namespace v0
...
#endif

With usage aka:

Suggested change

	namespace svs {
	namespace runtime {
	namespace v0 {
	inline namespace v0 {
	namespace svs {
	namespace runtime {
	SVS_API_V0 {
	...
	} // SVS_API_V0