Help: Tabnine suggestions are breaking my Prettier formatting

I've been integrating Tabnine into my team's development workflow for several months, primarily for our TypeScript and Terraform HCL work, and have observed a persistent, low-grade friction that is beginning to impact our code quality gates. The core issue is that Tabnine's inline code suggestions, while often contextually accurate, are introducing subtle formatting inconsistencies that directly conflict with our established Prettier configuration. This is not merely an aesthetic concern; it is breaking our CI/CD pipelines where `prettier --check` fails on otherwise syntactically valid code, causing unnecessary merge request rejections and developer frustration.

The conflict appears most pronounced in two specific areas:

* **Object literals and function arguments in TypeScript/JavaScript:** Tabnine will frequently suggest completions that use a different number of spaces for indentation than what Prettier enforces, or will place line breaks at different column thresholds. For instance, when completing a large object for a Kubernetes manifest in our TypeScript CDK, Tabnine will format it over multiple lines, but Prettier, set to a print width of 120, may decide to keep it on a single line, or break it at a different point.
* **HCL (Terraform) blocks:** Here, the issue is often with inline block suggestions. Tabnine might complete a `resource` or `data` block with its own internal spacing logic between arguments, which differs from Prettier's Terraform plugin formatting rules, particularly around the alignment of equals signs or the handling of multi-line strings.

Consider this trivial but representative example. I begin typing a Terraform local value:

```hcl
locals {
example =
```

Upon accepting a Tabnine suggestion for a complex map, I might receive:

```hcl
locals {
example = { key1 = "value1", key2 = "value2", key3 = "value3" }
}
```

However, our Prettier configuration (with `prettier-plugin-terraform`) formats this as:

```hcl
locals {
example = {
key1 = "value1"
key2 = "value2"
key3 = "value3"
}
}
```

The developer must now manually reformat the accepted suggestion, negating a significant portion of the efficiency gain. In a more complex scenario, such as a nested module block with numerous arguments, the discrepancy can be substantial.

My current workflow mitigation is to treat Tabnine as a first-pass autocompletion that I must immediately follow with a manual `Prettier: Format Document` command in VS Code (or save, if format on save is enabled). This feels suboptimal. I have explored the Tabnine configuration settings but have not found any native integration points or formatting-aware modes.

I am seeking architectural solutions or configuration patterns from the community. Has anyone successfully orchestrated a harmonious integration between Tabnine and a strict formatter like Prettier? Potential avenues I'm considering, but lack data on, include:

* Is there a method to make Tabnine's completion engine aware of, or even query, the project's `.prettierrc` file?
* Could a pre-commit hook be designed to *reformat* Tabnine's suggestions post-acceptance but before the file is staged? This seems complex for inline completions.
* Are there specific VS Code editor settings or Tabnine client-side configurations that defer more aggressively to the editor's own language server formatting capabilities?

The ideal state would be for the AI-assisted completion to be a seamless citizen in a codebase governed by deterministic formatting rules, without introducing cognitive load or pipeline failures.