[Future scope] Distinguish 'inferred' vs 'partial' contracts (#3998)

## What are you changing in this pull request and why?

Neither of these things exists yet — but they are distinct, and one is
likely to exist much sooner than the other!

Context:
-
dbt-labs/dbt-core#7432 (comment)

website/docs/docs/collaborate/govern/model-contracts.md

@@ -192,11 +192,12 @@ In some cases, you can replace a test with its equivalent constraint. This has t
 
 **Why aren't tests part of the contract?** In a parallel for software APIs, the structure of the API response is the contract. Quality and reliability ("uptime") are also very important attributes of an API's quality, but they are not part of the contract per se. When the contract changes in a backwards-incompatible way, it is a breaking change that requires a bump in major version.
 
-### Can I define a "partial" contract?
+### Do I need to define every column for a contract?
 
 Currently, dbt contracts apply to **all** columns defined in a model, and they require declaring explicit expectations about **all** of those columns. The explicit declaration of a contract is not an accident—it's very much the intent of this feature.
 
-We are investigating the feasibility of supporting "inferred" or "partial" contracts in the future. This would enable you to define constraints and strict data typing for a subset of columns, while still detecting breaking changes on other columns by comparing against the same model in production. If you're interested, please upvote or comment on [dbt-core#7432](https://github.com/dbt-labs/dbt-core/issues/7432).
+At the same time, for models with many columns, we understand that this can mean a _lot_ of yaml. We are investigating the feasibility of supporting "inferred" contracts. This would enable you to define constraints and strict data typing for a subset of columns, while still detecting breaking changes on other columns by comparing against the same model in production. This isn't the same as a "partial" contract, because all columns in the model are still checked at runtime, and matched up with what's defined _explicitly_ in your yaml contract or _implicitly_ with the comparison state. If you're interested in "inferred" contract, please upvote or comment on [dbt-core#7432](https://github.com/dbt-labs/dbt-core/issues/7432).
+
 
 ### How are breaking changes handled?
 
@@ -207,4 +208,5 @@ Breaking changes include:
 - Changing the `data_type` of an existing column
 - Removing or modifying one of the `constraints` on an existing column (dbt v1.6 or higher)
 
-More details are available in the [contract reference](/reference/resource-configs/contract#detecting-breaking-changes).
+More details are available in the [contract reference](/reference/resource-configs/contract#detecting-breaking-changes).
+