Discrepancy between spec and tests on indexing TypedDicts with unknown literal keys

Splitting issue from PR https://github.com/python/typing/pull/1978

Spec says that indexing with unknown literal keys should be reported as an error:

The use of a key that is not known to exist should be reported as an error, even if this wouldn’t necessarily generate a runtime type error. These are often mistakes, and these may insert values with an invalid type if structural assignability hides the types of certain items. For example, d[‘x’] = 1 should generate a type check error if ‘x’ is not a valid key for d (which is assumed to be a TypedDict type).

But it's not reflected in conformance tests (https://github.com/python/typing/blob/2d88da2a407b556f5b52b4c6ad1bd659873bb9ac/conformance/tests/typeddicts_operations.py) and there's a bit of discrepancy between type checkers how they handle some cases (most of them reject all cases that may cause runtime error / allow cases that do not cause runtime error ).

Would be great if we can either adapt conformance tests to the spec or amend the spec to remove the ambiguity.

Related discussion - https://discuss.python.org/t/typeddict-operations-with-unknown-literal-keys/89653 (also has information on state of this issue in different type checkers).

Compare the quoted spec requirement with conformance/tests/typeddicts_operations.py, then review the linked discussion and related PR for the differing type-checker behavior. Resolve whether the conformance tests or the spec should change; done means the ambiguity is settled and the spec and tests agree.