docs(README): add further clarifications and formatting to footnotes

README.md

@@ -110,11 +110,11 @@ Released under [MIT](./LICENSE) by [@freshgum](https://github.com/freshgum-bubbl
   P.S. Future maintainers: these footnotes are in order of *addition*, not appearance throughout the document.
   The ordering doesn't really matter anyway, as GitHub automatically sorts them in order of appearance (or so it seems).
 -->
-[^1]: Tested on 23/11/2023.  [A lot of work](https://github.com/search?q=repo%3Afreshgum-bubbles%2Ftypedi+bundle+size&type=commits) is made to reduce the size of the bundle *(a lot of work has also been inlined into other, non-related commits)*.  Note that bundle size tests are performed by copying the minified `typedi.min.mjs` file into [ByteSizeMatters](https://freshgum-bubbles.github.io/bytesizematters/) -- there are most likely better ways to test this.  Investigation on reducing bundle size is then performed by formatting the minified file with Prettier, and assessing the bundle for unnecessary code / possible refactors; this is done iteratively until I am unable to find any further code size optimizations (which would not negatively affect performance / result in breaking changes).  An example of a trick used to reduce the bundle size is name mangling: the [Rollup configuration file](./rollup.config.mjs) contains code to minify certain members of internal classes (such as `VisitorCollection`).
+[^1]: **Tested on 23/11/2023**.  [A lot of work](https://github.com/search?q=repo%3Afreshgum-bubbles%2Ftypedi+bundle+size&type=commits) is made to reduce the size of the bundle *(a lot of work has also been inlined into other, non-related commits)*.  Note that bundle size tests are performed by copying the minified `typedi.min.mjs` file into [ByteSizeMatters](https://freshgum-bubbles.github.io/bytesizematters/) -- there are most likely better ways to test this.  Investigation on reducing bundle size is then performed by formatting the minified file with Prettier, and assessing the bundle for unnecessary code / possible refactors; this is done iteratively until I am unable to find any further code size optimizations (which would not negatively affect performance / result in breaking changes).  An example of a trick used to reduce the bundle size is name mangling: the [Rollup configuration file](./rollup.config.mjs) contains code to minify certain members of internal classes (such as `VisitorCollection`).
 [^2]: No *runtime* dependencies are included.  The only dependency of this package is [type-fest](https://github.com/sindresorhus/type-fest) (which only provides TypeScript types which are used internally).  This dependency has been [version-locked](https://github.com/freshgum-bubbles/typedi/blob/develop/package.json) to ensure any breaches of that package's security does not impact anyone using this package.  Any updates are checked and verified to ensure they do not contain malicious code.
 [^3]: This mainly refers to the package's standard container-based interface, which makes testing easy (as you can replace services and values at any time).  Further work is being done on a more featureful testing suite, which would be able to simplify the overall testing process.
 [^4]: I haven't counted each one, but I'd say that the package exports ~40 types (as of writing: 23/11/2023); a lot of the safety is provided through typing, as opposed to unnecessary runtime checks, which affect performance and code size.
 [^5]: In the future, I'll most likely look at renaming this package.  That'll come naturally as part of a wider project.  You'll probably notice that I avoid explicitly using this package's name in a lot of places; that will make it easier to update.  The naming scheme is... unfortunate, and in retrospect I should have named it differently to avoid confusion with the original project.
 [^6]: One example of such a project is [ListenBrainz Discord RPC](https://github.com/freshgum-bubbles/listenbrainz-discord-rpc), which makes use of this package to structure its functionality into modular services.  There are some other examples on GitHub's *Dependents* view, too.
 [^7]: An example of "magic", in this context, would be integration with the filesystem to read a configuration file in a proprietary format, and then using that to configure services -- while that might make more sense for Java developers, such features don't (in my experience) scale well in JavaScript.  Also, we'd have to write a ton of editor integrations! `</ramble>`
-[^8]: If the library is ever feature-complete, it'll still be maintained -- compatibility with the latest engines will still be tested.  However, as stated prior, features would not be added for the sake of adding features.  Therefore, if this package ever *becomes* feature-complete (and is placed into maintenance mode), **there's no need to ask if it's abandoned.**  If there haven't been any commits for over a year, it probably is; in that case, please fork it and continue my efforts.  All power to you!
+[^8]: If the library is ever feature-complete, **it'll still be maintained** -- compatibility with the latest engines will still be tested.  However, as stated prior, features would not be added for the sake of adding features.  Therefore, if this package ever *becomes* feature-complete (and is placed into maintenance mode), **there's no need to ask if it's abandoned.**  If there haven't been any commits for over a year (which is a very unlikely scenario, unless it's been superseded by something which is demonstrably better), it probably is; in that case, please fork it and continue my efforts.  All power to you!