TOML, Java Properties double-close File/Path source on construction failure

FasterXML/jackson-core#1693 moved ownership of "close what Jackson opened" into `TextualTSFactory`/`BinaryTSFactory`: their `createParser(File)` / `createParser(Path)` now close the stream if construction fails. The same PR removed the equivalent `[core#763]` guard from `JsonFactory._createParser(ObjectReadContext, IOContext, InputStream)`, because keeping both meant closing twice.

TOML and Java Properties still have their own copy of that guard, so they now double-close:

- `TomlFactory._createParser(..., InputStream)` (:173) wraps in `UTF8Reader(ctxt, in, autoClose)` with `autoClose = ctxt.isResourceManaged() || AUTO_CLOSE_SOURCE`, and `parse()` (:235) closes it via `try (Reader r = r0)` — which fires on the exception path.
- `JavaPropsFactory._loadProperties(Reader, IOContext)` (:302) does the same under the same condition.

Both parse eagerly during construction, so this is the common path rather than an edge case: any TOML or `.properties` syntax error read from a `File`/`Path` source closes the underlying stream twice.

Harmless today — `FileInputStream.close()` is idempotent — but a user `InputDecorator` returning a non-idempotent stream will throw on the second close, and that lands as a spurious suppressed exception on the user's real failure. That is exactly what the jackson-core change avoided.

Suggested fix, matching jackson-core: drop the close from the backend and let the base class own it. YAML, CSV and XML already work this way and need no change.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01XrYRabZTvG9TjdXTCghvaM