item() reorders keys (dict-valued before scalar) even with the default sort_keys=False

[pramodavansaber]

Summary

When tomlkit.items.item() builds a value from a Python list of dicts, its sort key has a misplaced parenthesis:
key=lambda i: (isinstance(i[1], dict), i[0] if _sort_keys else 1). The if _sort_keys else 1 guards only i[0], so the isinstance(i[1], dict) term stays active — dict-valued keys are forced after scalar-valued keys even when sort_keys=False. The sibling top-level branch guards the whole tuple correctly: (isinstance(i[1], dict), i[0]) if _sort_keys else 1.

Reproduction

from tomlkit.items import item
print(item([{'a': {'x': 1}, 'b': 2}]).as_string())
# b = 2
#
# [a]
# x = 1

Input key order is a, b, but b is emitted before the [a] table.

Expected

With the default sort_keys=False, key order is preserved: the [a] table, then b = 2.

Actual

b = 2 is emitted before [a] — keys silently reordered.

Fix sketch

Guard the whole sort tuple with _sort_keys, matching the top-level dict branch.

Environment

tomlkit 0.15.0 (master @ 43668dd), Python 3.12.

[dimbleby]

If b were emitted after the [a] table then it would no longer be a top-level scalar, and the document would not match the dictionary.

[apoorva-01]

Took a look after #547 got closed. dimbleby's point there is right: dicts-last is capture-avoidance, so a top-level scalar renders before a [sub.table] header instead of getting swallowed into it. Making it conditional on sort_keys breaks that, which is why that PR didn't hold up.

But that same reasoning points at what's actually off here. Capture only happens for keys that render as table headers. Inline tables are single-line {...}, so they can't capture anything, yet their keys still get reordered under the default sort_keys=False:

>>> item([[{"a": {"x": 1}, "b": 2}]]).as_string()
'[[{b = 2, a = {x = 1}}]]'

So the sort key could key off the constructor instead of sort_keys: keep dicts-last for the Table/AoT path (those produce headers and can capture), and preserve insertion order for InlineTable (it can't). That resolves #546 without trading away capture-safety, and it makes the two branches in item() consistent with each other.

Worth a PR, or would you rather leave #546 as cosmetic? Just checking before I head the same way as #547.