noPropertyAccessFromIndexSignature -> noUncheckedIndexedAccess

This was just a mental flub: it was always intended to be the latter,
and I just repeatedly typo'd it.

text/0730-semver-for-ts.md

@@ -64,7 +64,7 @@ Note that this summary elides *many* important details, and those details may su
 
 -   Packages must be authored with the following compiler options:
     -   `strict: true`
-    -   `noPropertyAccessFromIndexSignature: true`
+    -   `noUncheckedIndexedAccess: true`
 
 -   Libraries should generally be authored with the following compiler options:
     -   `esModuleInterop: false`
@@ -605,7 +605,7 @@ Bug fix/patch releases to TypeScript (as described above under [Bug fixes](#bug-
 
 Type-checking in TypeScript behaves differently under different “strictness” settings, and the compiler adds more strictness settings over time. Changes to types which are not breaking under looser compiler settings may be breaking under stricter compiler settings.
 
-For example: a package with `strictNullChecks: false` could make a function return type nullable without the compiler reporting it within the package or the package’s type tests. However, as described above, this is a breaking change for consumers which have `strictNullChecks: true`. (By contrast, a *consumer* may disable strictness settings safely: code which type-checks under a stricter setting also type-checks under a less strict setting.) Likewise, with `noPropertyAccessFromIndexSignature: false`, an author could change a type `SomeObj` from `{ a: string }` to `{ [key: string]: string }` and accessing `someObj.a.length` would now error.
+For example: a package with `strictNullChecks: false` could make a function return type nullable without the compiler reporting it within the package or the package’s type tests. However, as described above, this is a breaking change for consumers which have `strictNullChecks: true`. (By contrast, a *consumer* may disable strictness settings safely: code which type-checks under a stricter setting also type-checks under a less strict setting.) Likewise, with `noUncheckedIndexedAccess: false`, an author could change a type `SomeObj` from `{ a: string }` to `{ [key: string]: string }` and accessing `someObj.a.length` would now error.
 
 Accordingly, conforming packages must use `strict: true` in their compiler settings. Additionally, communities may define further strictness settings to which they commit to conform which include “pedantic” strictness settings like `noUncheckedIndexedAccess`. For example, the Ember community might commit to a set of *additional* strictness flags it supports for its own types for any LTS release, published in Ember’s own TypeScript documentation.
 
@@ -637,7 +637,7 @@ To conform to this standard, a package must:
 - specify the compiler support policy
 - specify the currently-supported versions of TypeScript
 - specify the definition of “public API” used by the library (e.g. “only documented types” vs. “all published types” etc.)
-- author and publish its types with `strict: true` and `noPropertyAccessFromIndexSignature: true` in its compiler configuration
+- author and publish its types with `strict: true` and `noUncheckedIndexedAccess: true` in its compiler configuration
 
 
 ## How we teach this